HSUPA作为HSDPA的孪生姐妹，虽然风头不如HSDPA强劲，但是随着标准的稳定、技术的成熟、产品的面试，伴随着各方的吹嘘鼓噪，在2006年一样会家喻户晓。　　大部分业内人士相信，由于话音、高速的数据和多媒体等业务将会在不久的将来更有效地整合。利用IP技术同时承载话音、高速的数据和多媒体业务，会使运营商更有效地管理整个网络和降低网络的运营成本，同时比较容易推出新的业务。因此，3GPP应运而出的HSUPA即成为WCDMA无线技术在HSDPA之后的进一步演进的标准，该标准已于2004年3月冻结，今年3月份全部CR已完成，预计2007年中即会有相应的预商用产品，在2008年即会商用。
一、HSDPA/HSUPA的关键技术
　　1.新信道的引入
　　为了支持高速业务，HSDPA/HSUPA都引入了新的物理信道。
　　(1)HSDPA
　　高速物理下行共享信道(HS-PDSCH：HighSpeedPacketData Shared Channel)：承载实际分组数据，扩频因子（SF）＝16，QPSK和16QAM，每小区最多15个HS-PDSCH，累积数据峰值速率达到14.4Mbit/s。在单用户使用15个HS-PDSCH，16QAM调制以及编码速率为1的情况下实现。
　　高速共享控制信道(HS-SCCH：HighSpeedSharedControl Channel)：承载信令信息的下行信道（信道码集、调制方案、传输块大小、HARQ处理号、冗余和星座版本参数、新数据标记和UE标识），SF＝128，QPSK由Node B进行功率控制，每小区最多32个HS-SSCCH，每用户设备最多4条HS-SCCH。
　　高速专用物理控制信道(HS-DPCCH：HighSpeedDedicatedPhysical Control Channel)：承载信令信息的上行信道(ACK/NACK及信道质量指示（CQI）)，SF＝256，QPSK中止于Node B。
　　HS-PDSCH、HS-SCCH和HS-DPCCH使用2ms传送时间间隔（TTI）。
　　(2)HSUPA
　　E-DCH——专用物理数据信道(E-DPDCH：E-DCHDedicatedPhysicalData Channel)：承载E-DCH的上行数据信息，扩频因子SF=64、32、16、8、4、2，UE根据业务的需要灵活选择。QPSK调制映射到传输信道E-DCH，单码道的最大速率为1.92Mbit/s，允许多码传输，峰值速率5.76Mbit/s，在2个SF=2、2个SF=4的4码道并行传输的情况下实现。
　　E-DCH——专用物理控制信道(E-DPCCH：E-DCHDedicatedPhysicalControl Channel)：承载E-DCH的上行信令信息，它与E-DPDCH的信道结构相似，SF=256。
　　E-DCHHARQ确认指示信道(E-HICH：E-DCHHARQAcknowledgement indicator channel)：承载E-DCH下行信令信息的专用信道，如HARQ的ACK/NACK信息。扩频因子SF=128，没有信道编码。使用3或者12个连续的时隙发送信息，每个时隙采用40个数据的复用，因此单个E-HICH最大支持上行40个用户的反馈。UE监测激活集中所有小区的E-HICH信道。当TTI为2ms时，该信道每2ms上报一次信息；当TTI为10ms时，该信道每8ms上报一次信息。
　　E-DCH相关准予信道(E-RGCH：E-DCHrelativegrant channel)：承载E-DCH的下行相关信息，该信道SF=128，没有信道编码。使用3、12或15个连续的时隙发送信息，与E-HICH一道采用三维的数字标记复用在同一条SF=128的下行信道上，每时隙数据长度为40，因此单个E-RGCH最大支持上行40个用户的功率指示。该信道分为两种，服务小区（Serving Cell）下的E-RGCH及非服务小区（Non-serving Cell）下的E-RGCH，服务小区下的E-RGCH是专用信道，携带指示UE的功率上升、保持、下降的指令信息，如UP、HOLD、DOWN。当TTI配置为2ms时，该信道2ms下发一次调度指令；当TTI配置10ms时，该信道8ms下发一次。非服务小区下的E-RGCH是公共信道，携带小区的负载指示信息，如当前负荷情况，是否超载，调度时延总是10ms。
　　E-DCH绝对准予信道(E-AGCH：E-DCHabsolutegrant channel)：承载E-DCH的下行绝对信息，如小区信息。每个配置E-DCH的UE只需要监听服务小区的E-AGCH信道即可，该信道是公共信道，SF=256。
　　上述信道支持2ms、10ms的TTI帧格式。因此有别于HSDPA的2msTTI。
　　2.混合自动重传+软合并（HARQ）
　　为了进一步提高系统性能，HSDPA/HSUPA在物理层都采用了HARQ技术，同样都支持两种合并机制：对基站重发相同的分组包进行前后合并(CC：ChaseCombing)或对基站重发含有不同信息（即冗余信息）的分组包进行增量冗余合并(IR：IncrementRedundancy)。信息在UE与NodeB间直接传输，采用ACK/NACK的方式进行，当接收方正确接收数据后，会通过相应的信道向发送方发送ACK信息，否则发送NACK信息，这样便于发送方准确及时地了解是否需要重传。
　　HSDPA采用HARQ方案，使得重传时延控制在10ms左右。HSUPA采用HARQ，在10ms的TTI下，重传时延为40ms；2msTTI下，重传时延为16ms。与R99/R4的无线侧重传时延100ms相去甚远，因此HARQ的引入大大提高了重传的效率和解码的性能。
　　两者惟一的差别是HSDPA采用了异步的HARQ，而HSUPA采用同步的HARQ。
　　3.基于Node B的快速调度(Node-B Scheduling)
　　为了对无线环境及时快速的做出响应，最大化资源效率，HSDPA/HSUPA都采用了基于NodeB的快速调度方案。但是上下行要解决的问题不一样，因此上下行调度的机制存在差异，下面分别介绍。
　　(1)HSDPA
　　HSDPA中的调度主要由NodeB中新增的MAC-hs功能实体完成。HSDPA调度的核心思想是合理分配共享资源（码字、功率），最大化资源的利用率。HSDPA的调度很大程度上决定了AMC和HARQ的效率和性能，决定了整个系统的行为。简单的说，HSDPA的调度基于以下因素：队列优先级（Queuepriority）、信道质量指示值（CQIvalue）、缓存大小（Buffer volume）、等待时间/空闲时间（waiting time/Spare time），其它如UE能力、ACK/NACK重复次数、数据重传、压缩模式等。基于上述因素，又形成了行业默认的三种调度算法：基于最大载干比的调度算法（Max C/I算法）、基于公平分配的调度算法（Round Robin算法）和基于部分公平的调度算法（Proportional Fair算法）。
　　对于不同的算法，不同厂家支持及实现的方式有一定的差异。一般来讲主要采用参数化的调度器，分配资源可以考虑以下因素：f1，业务等级；f2，CQI；f3，等待时间；f4，队列长度。这些因素作为加权因子，决定了实际的资源分配方法：Pi=a×f1+ b×f2 + c×f3 + d×f4，a/b/c/d 为加权因子。运营商可以根据HSDPA的应用场景，如微微蜂窝、微蜂窝、宏峰窝等因素，来决定相关的加权因子，实现最优的资源调度方案。
　　(2)HSUPA
　　HSUPA中的调度主要由NodeB中新增的MAC-e功能实体完成。HSUPA调度的核心思想是避免过多的UE接入过高的速率，从而给系统带来干扰，即尽可能抑制上行干扰，同时服务小区对调度起主要作用。
　　E-DCH信道支持调度及非调度两种模式。非调度主要是在小区负载轻，上行用户数据量不大的情况下使用。非调度模式的传输类似于R99/R4的DCH信道，信息中止与RNC，这种方式有利于低数据量及时延敏感的业务。本节主要讨论E-DCH信道的调度原理及方法。
　　基于NodeB的上行调度有两个关键因素，即调度请求和调度准许。
　　调度请求即当UE希望用更高的数据速率发送时，移动终端向基站发送请求信号，也包括UE向基站反馈的调度信息Happybit，该信息告诉基站，UE对当前的调度是否满意，以便基站下一次调整相应的调度策略。
　　调度准许由基站下发，主要限制UE的E-DCH信道可用的最大功率以及可用的最大E-TFC。每个UE有自己的服务准许（ServingGrant），它影响E-TFC的选择。服务准许包括两方面的内容：绝对准许及相对准许。绝对准许的内容为小区信息，E-DCH的绝对功率偏置（相对DPCCH）以及UE可用的PrimaryE-RNTI及SecondaryE-RNTI。当UE的上传数据量非常大时，Node B会指示它使用主RNTI资源。当UE的上传数据量较小或没有时，Node B会指示它使用辅E-RNTI，即与其他用户一起共享E-RNTI的资源。每个UE都有主辅两种E-RNTI，只是何时使用哪种E-RNTI，由Node B通知。相对准许指示包括E-DCH信道功率的相对上升/保持/下降（UP/HOLD/DOWN）等信息。UE的服务准许可根据绝对准许及相对准许的改变而更新。处于主E-RNTI的UE，Node B会采用专用的调度机制；处于辅E-RNTI的UE，Node B采用一般调度方案。
　　从上述的描述中可见，NodeB依据用户的信道质量及所需传输的数据状况来决定UE所应该使用的E-RNTI，同时依据小区负载、Iub接口资源占用情况，决定UE可用的最高传输速率及何时传输。当然UE实际使用的TFC由UE决定，同时由E-DPCCH信道上传给NodeB。UE通过Happybit反馈对当前的调度是否满意，以便下次Node B改变调度方式。
　　如同HSDPA一样，调度信令是在基站和移动终端间直接传输的，所以基于NodeB的快速调度机制可以使基站灵活快速地控制小区内各移动终端的传输速率，使无线网络资源更有效地服务于访问突发性数据的用户，从而达到增加小区吞吐量的效果。
　　UE的重传不在NodeB调度的范围内，NodeB的调度也不会影响到重传。调度只针对初始传输的数据。
　　4.快速链路适配
　　WCDMA系统下行采用扰码（Gold序列）区分小区，扩频码（OVSF&Walsh码）区分用户，上行采用扰码（Gold序列）区分用户，而扩频码（OVSF&Walsh码）区分信道。由于扩频码完全正交，因此下行不存在用户间的远近（Near-Far）效应，而扰码自相关性好，而互相关性差，不完全正交，因此上行存在用户间的远近效应。为了应对不同的情况，上下行也采用了不同的策略。
　　(1)HSDPA
　　HSDPA能够充分利用R99/R4DCH+CCH以外的剩余功率，使得资源利用率最大化。HSDPA采用码率匹配(RateMatching)的方式，即灵活根据当前的功率占用情况，来选择相应的传输速率。因此，HSDPA不采用功率控制，这也是为什么HSDPA一定要采用2ms帧长的原因。如果帧长10ms或者更长，HSDPA就难以跟踪信道的变化，难以实现快速的链路适配（500次/秒）。
　　(2)HSUPA
　　为了克服上行用户间的远近效应，HSDPA采用了上行的功率控制方案。E-DPDCH/E-DPCCH的初始功率设置与DPCCH有一定的偏置。因此E-DCH的功率控制完全依据DCH的功率变化而变化。但是E-DCH的外环功率控制依据“重传的次数”进行，而不是BLER，因为HARQ的原因，不断地重传，BLER不会差。同时，为了保证控制信道的有效性，一般来讲，E-DPCCH的功率偏置较E-DPDCH的大。
　　HSUPA在功控的基础上，实现了上行的软切换及更软切换，这是HSDPA不具备的，HSDPA只有硬切换。
二、HSDPA/HSUPA的终端
　　1.HSDPA
　　根据GSA的调查，截至2006年4月24日，全球已有94家移动运营商计划部署HSDPA网络，目前18个HSDPA网络在14个国家（奥地利、保加利亚、捷克、芬兰、德国、马恩岛、以色列、科威特、Madeira、荷兰、菲律宾、葡萄牙、南非、美国）已开始商用。截至今年年底至少还有29个网络将会开展商用。因此，HSDPA的商用形势一片大好。
　　按照3GPP的要求，依据支持的调制方式，最大可用码道的能力以及TTI的间隔将HSDPA终端分为12类。提供商主要有华为、中兴、SierraWireless、Option、NovatelWireless、西门子、三星、LG、NEC、摩托、富士通等。2005年3季度及更早，运营商测试的终端主要是12类别的终端-峰值1.8Mbit/s的数据卡。今年在巴塞罗那的通信展上，LG、NEC已经展示了12类别的终端。目前，部分厂商已经可以提供峰值3.6Mbit/s的终端及数据卡，预计在今年6月份能够推向市场开始商用。此外，高通支持7.2Mbit/sHSDPA芯片已面世，杰尔宣布推出3.6Mbit/s HSDPA芯片组，英飞凌则面向中端多媒体电话市场推出7.2Mbit/s HSDPA处理器样品。如据GSA调查，截至2006年2月28日，HSDPA终端的已增至25款。相对过去的6个月，增长了50%。因此，随着HSDPA网络的进一步铺开，商用模式的成功，将会有越来越多的HSDPA终端提供商及更多类型的终端面世。
　　2.HSUPA
　　按照3GPP的规定，HSUPA终端共有6类。支持2msTTI的仅有3种，6种中最大速率是5.76Mbit/s。
　　如同HSDPA一样，芯片厂商对HSUPA终端的支持也是分阶段进行，预计商用初期，还是倾向于使用10ms的TTI，即2Mbit/s的终端，逐渐支持到5.76Mbit/s。
　　高通对外宣称，今年上半年推出首款支持HSUPA的功能的芯片MSM7200，该芯片后向兼容UMTS、HSDPA、GSM/GPRS/EDGE，上下行峰值速率分别为2Mbit/s，3.6Mbit/s，目前正处于实验室内部测试阶段。
　　从整个行业的情况看，在全球全IP网络AIPN（AllIPNetwork）的发展趋势下，伴随着VoIP的升温，多媒体业务的广泛应用，HSUPA的引入势在必行。
三、HSDPA/HSUPA的性能分析
　　HSDPA在前期已经讨论很多，这里只要讨论HSUPA。
　　在3GPP规范讨论过程中，对HSUPA研究最终认为使用QPSK调制编码，上行H-ARQ的应用，NodeB控制上行调度，更短的帧结构和快速DCH建立会达到50～70%的上行容量增益，数据呼叫时延减少20～55%，用于上行平均数据呼叫的速率可提高大概50%。但是由于目前HSUPA还没有相应的产品及试验数据，因此具体能够实现什么样的性能还不清楚。
　　但是，HSUPA采用了与CDMA20001xEV-DO基本相同的技术及原理，因此我们可以借鉴当前已计划年底商用的EV-DO RevA现网观测数据的仿真性能。
　　1.容量——平均小区吞吐量
　　基本假设：15个用户被放在每个小区(1.25MHz)，总共有57个小区，单载波宏蜂窝网络，并只提供数据业务。通过仿真分析得出结果如表2所示。
表2 EV-DO Rev0与RevA的上行吞吐量对比
Rev.0 Rev.A
信道模型 用户吞吐量 （kbit/s） 小区吞吐量（kbit/s） 用户吞吐量（kbit/s） 小区吞吐量（kbit/s） 增益（%）
A 18.9 283 33.8 507 79
B 12.8 192 24.2 363 89
C 13.9 208 24.4 366 76
D 18.9 283 33.2 498 76
E 26.9 403 39 586 45
3GPP2
混合信道 16.3 244 28.9 434 78
　　从表2看出，Rev.A的上行容量会比Rev.0高75%以上，比3GPP对HSUPA和R99的模拟结果（50%到70%）略高。
　　2.QoS保证的业务能力（VoIP）
　　基本假设：单载波小区，并只提VoIP业务。具体结果如表3所示。
表3 EV-DO RevA网络ROT与上行负载的关系
Erl 35 37 38 39 40 41
平均ROT（dB） 4.14 4.54 4.95 5.03 5.35 5.57
上行负载（%） 70.7 72.7 73.75 74.15 75 80
　　从表3CDMA20001x的干扰和热噪声的比例可以看出，当ROT接近5dB时，上行链路负荷已达到75%左右。这也就是表明，每个1.25MHz的可支持的VoIP话务量约40Erl.，略为高出CDMA2000 1x1x RTT的话音容量。
　　由于HSUPA和CDMARev.A的关键技术非常接近，从以上的CDMA20001xRTT Rev.A的模拟结果和现网观察可以认为这个结论相对可靠和保守。但是，假如HSUPA和R99/R4/R5混合在同一载波组网（1x EVDO RevA.不存在这个问题），HSUPA用户的使用，会导致网络的上行瞬间干扰会明显提高，对R99/R4的覆盖可能会有一定的影响，需要对其做出更深入分析。
四、HSDPA/HSUPA标准演进
　　HSDPA+HSUPA的演进项目，即E-HSPA（Evolved-HighSpeedPacketAccess）已在今年3月份的3GPP全会上提出。E-HSPA提案是一部分拥有较多HSDPA、HSUPA专利的厂商（Ericsson、Nokia、Alcatel等），希望继续发挥相关专利的价值，同时部分已部署或即将部署HSDPA网络的运营商（Cingular等）希望3G拥有一个较长的生命周期而有针对性地提出的提案，并希望它归入3GPP R7的范畴。
　　E-HSPA提案从支持者的角度看，不需要额外的频率资源（利用原有WCDMA的5MHz带宽），在同等的频段（5MHz）内达到与LTE（LongTermEvolution）一样的性能。此外只是将原来增强的上下行技术HSDPA、HSUPA综合考虑，实现资源利用率最大化。E-HSPA与WCDMA的关系相当于EDGE与GPRS的关系。即无线侧设备的软件升级即可实现的技术。
　　同时，E-HSPA的网络架构类似于LTE已确定的网络架构，它们可共享核心侧，即SAE，惟一的差别就是无线侧。因此支持者认为这样可实现E-HSPA到LTE的平滑网络升级，充分利用已有投资，节省成本。
　　以Cingular为代表的运营商、设备提供商极力推荐3GPPRAN采用E-HSPA方案，虽然NTTDocomo、T-mobile、Samsung等提出反对意见，但是RAN侧考虑问题的局限性，认为E-HSPA技术只是UTRAN的简单软件升级，不涉及到大的规模性的改动，也不影响LTE的网络架构，因此在RAN#31次会议上最终通过。但是当提交到SA#31上讨论时，以T-mobile、Samsung为代表的厂商再一次提出众多的质疑，认为E-HSPA方案的引入会影响到LTE的进程，同时会影响到SAE方案中的e-Node B与e-GW的接口S1，即会对e-GW的功能改动很大，不可能实现E-HSPA到LTE的平滑升级，因此在SA全会中，以Cingular为代表的E-HSPA提案暂时标注为noted，即下次大会再讨论。在2006年3月到6月间，各支持方及反对方都要拿出强有力的仿真数据，支持各自的观点，以便下次SA全会讨论，相关动向我们将拭目以待。


文章是很多年前的了，觉得很多技术细节对我们很有帮助，就摘来分享！