WCDMA HSPA向LTE的演进Word文档格式.docx
- 文档编号:21297622
- 上传时间:2023-01-29
- 格式:DOCX
- 页数:12
- 大小:1.14MB
WCDMA HSPA向LTE的演进Word文档格式.docx
《WCDMA HSPA向LTE的演进Word文档格式.docx》由会员分享,可在线阅读,更多相关《WCDMA HSPA向LTE的演进Word文档格式.docx(12页珍藏版)》请在冰豆网上搜索。
LTE是真正的宽带无线多媒体网络,他将会使移动互联网的重要支撑网络,包括移动性、个人用户身份特征的一些移动创新业务的支撑网络;
WCDMA/HSAP运营网络迈向LTE的演化过程:
---技术途径可以有多种选项;
---是一个2G/3G/LTE网络资源和投入融合的过程;
---与终端密切互动,端和云加速结合。
注重移动网络智能管控,
最终,将通过精细化的流量管控和开放网络能力的模式,实现个性化服务和差异化计费,帮助运营商充分利用网络资源,提高网络收益并开创新的商务模式。
1WCDMA/HSPA演进考虑:
【HSPA+、LTE、LTEAdvanced】
在WCDMA建网以HSPA为起点的情况下,向LTE/LTE+的演进有两条路线。
1)方案一:
HSPA直接向LTE演进
该方案在适当时机引入LTE技术,更多的会话类业务和PS数据业务承载LTE上。
其优势是LTE标准制定进度和技术发展较顺利,厂家重视与支持程度较好;
相对于HSPA+,LTE系统也能提高更高的应用速率。
但由于LTE重新定义了空中接口和网络结构,以OFDM为核心技术,与3G系统的CDMA技术相比,存在本质上的差别,因此与已有3GPP各版本不兼容,UTRAN网络移动台无法接入LTE网络,UTRAN网络网元也无法直接实现与LTE网元共用。
与3GPP2CDMA阵营的运营商(如:
Verizon…)情况不同,对于3GPPWCDMA/HSPA运营商(如中国联通,AT&
T…)来说,该种方案演进过程过于激烈,大量HSPA用户需要更换终端,HSPA网元无法再利用,3G网络投资保护性差。
2)方案二:
通过HSPA+过渡向LTE演进
该方案在HSPA基础上引入HSPA+,以提高HSPA性能(数据峰值速率等),然后逐步引入LTE。
其优势是演进平滑,现有网络投资可以得到最大限度的保护。
⏹HSPA+是HSPA演进的下一个步骤,对于3GPP运营商,其吸引力在于:
能在不改变现有网络结构的前提下,通过引入64QAM、MIMO等技术,进一步提高频谱效率和峰值速率,降低延迟,更好的支持VOIP和多播业务。
⏹HSPA+技术已经在ALU的众多客户中,广泛采用。
除了CU已经激活了64QAM功能外,国外大运营商也都已激活该功能,比如:
AT&
T、OrangeFrance、SRF(France)、Mobilkom(Austria)、Telecom(NewZealand)、以及Vodafone集团等。
HSPA+采用的主要改进有:
1)下行/上行采用64QAM/16QAM方式。
调制阶数越高,每调制符号能承载的比特个数越多。
因此在在相同符号速率下,调制阶数越高,相应的比特速率就越高。
HSPA+下行/上行分别采用64QAM/16QAM方式,可以支持下行/上行高达21Mbps/11Mbps的峰值速率。
2)多天线技术。
多输入—多输出(MIMO)技术在通信链路两端均使用多个天线,发端将信源输出的串行码流转换成多路并行子码流,分别通过不同的发射天线阵元同频、同时发送,接收方则利用多径引起的多个接收天线上信号的不相关性从混合信号中分离估计出原始子码流。
这相当于频带资源重复利用,可以在原有的频带内实现高速率的信息传输,使频谱利用率和链路可靠性极大的提高。
MIMO将多径无线信道与发射、接收视为一个整体进行优化,从而实现高的通信容量和频谱利用率。
在HSPA基础上引入2X2MIMO技术,下行峰值速率可以到达28Mbps,但硬件上需要增加一幅天馈系统,同时需要软件升级。
如果同时采用64QAM和2X2MIMO技术,下行峰值速率可以到达42Mbps。
3)改进层2以支持高数据速率。
通过引入MIMO、下行64QAM、上行16QAM等技术提高了物理层峰值速率;
但与LTE相比,RLC峰值速率受限于RLCPDUsize、RTT和RLCwindowsize,fixedPDUsize的RLC在某些场景下成为系统性能瓶颈。
在下行,对HS-DSCH信道,通过flexibleRLCPDUsize及引入新MAC实体MAC-ehs,可以提高L2速率,降低协议开销;
在上行,对E-DCH信道,通过flexibleRLCPDUsize及引入新MAC实体MAC-i/
is,同样可以降低信令开销。
4)其他性能增强技术。
在HSPA+中,为了进一步增强实时业务的QOS和系统性能,缩短与LTE的差距,引入了一些新技术,如增强的ELLFACH(以减少信道建立和分配的延迟,增加Idle、CELL-FACH、CELL-PCH和URA-PCH的可用峰值速率)、UEDRX、CPC(ContinuousPacketConnectivity)等。
HSPA/HSPA+下行技术提升,与版本关系如下图所示
HSPA/HSPA+上行技术提升途径,与版本关系如下图所示
2WCDMA/HSPA演进考虑:
【LTE的引入优势】
在HSPA基础上引入HSPA+的优势是平滑演进,在网络改造投入和网络效能之间寻求最佳平衡点,以最小代价逼近LTE水平。
但是HSPA+最终不能替代LTE。
LTE的部署既有技术驱动因素,也有竞争驱动因素(如:
T与Verizon的LTE竞争部署)
与HSPA+比较,LTE有下述特点:
1)网络架构方面,LTE采用全IP扁平化的网络结构,减少了网络的层次和网元数目,从而降低的运营商网络建设的成本投入。
⏹LTER8/R9特点是高效频谱,低时延和可变带宽;
最主要是通过LTE采用的关键技术包括高效的频谱利用,扁平化的网络利用,带来了成本的接受,使网络部署,设备成本得到极大的降低,这为运营商突破网络的性能和成本的限制,提供一些我们所看到的高带宽需求以及所谓互联网的业务,提供了非常好的基础。
低成本提供宽带移动业务是一般认为,运营商开展LTE业务非常关键的因素
2)从技术方面讲,多载波技术OFDM相对于HSPA沿用的WCDMA的单载波直序扩频技术有着天生的优点,特别是在对大的系统带宽支持上。
⏹由于各个载波可以重合,OFDM在理论上可以接近乃奎斯特极限,是现在所有多址技术当中,效率最高的。
OFDM可以有效的避免小区内用户间干扰,而CDMA技术一定是要在接收端做信道均衡和多用户检测。
⏹带宽的可扩展性强,多载波技术的系统带宽取决于子载波的个数,而CDMA技术只能靠提高码片速率来提高系统带宽,这样会造成整个系统,尤其是UE的复杂度大幅度上升。
⏹OFDM对于多径衰落的良好抗性,ISI的性能远远好于CDMA技术,CDMA技术在系统带宽超过5M之后,做消除多径衰落均衡器的复杂度会大大上升。
⏹对于MIMO,OFDM技术的支持也大大超过CDMA,主要还是因为OFDM技术的ISI比较小,如果天线间干扰和ISI混在一起,MIMO实现的复杂度将大大提升,OFDM在这一方面也是具有优势的。
3)产业链方面,
现在应该选择LTE作为演进计划的运营商数量逐渐增多,商用条件开始成熟;
终端方面,HSPA+只有在rel-8引入MIMO和64QAM才能和LTE的速率接近,目前支持rel-8HSPA+的终端数量,与为了LTE的芯片或终端供货能力差距不多。
4)未来演进
特别LTER10“LTE-Advanced”:
LTE-A是LTE的平滑演进,与LTER8/R9保持后向兼容;
支持多种覆盖场景,提供从宏蜂窝到室内场景的无缝覆盖;
重点解决低速移动环境中的高速数据传输,包括进一步降低技术成本和能耗等;
性能指标是系统带宽大于20MHz,支持的下行峰值速率为1Gbit/s,频谱效率提高到30bit/s/Hz,上行峰值速率为500Mbit/s,频谱效率提高到15bit/s/Hz。
LTE-A系统将下行天线扩展到8×
8,上行天线扩展到4×
4,并且引入了载波聚合技术、中继技术和多点协作传输技术平滑,现有网络投资可以得到最大限度的保护。
WCDMA/HSPA演进考虑:
【择机过渡】
HSPA+过渡到LTE的时机点,取决于3方面因素考虑:
单用户峰值能力/小区吞吐量/HSPA+MIMO利弊
1)HSPA+的单用户峰值能力
下行峰值速率:
【10MHSPA+(64QAM+5MDC)和10MLTE2×
10M(2*2MIMO,Cat3UE)能力相当】
注释1:
下图FDD20M能力图经过指数变形或受CAT3能力限制,不做参考
注释2:
考虑到HSPA+MIMO的硬件COST和性能方面诸多限制,故不做比较
上行峰值速率:
【5MHSPA+(16QAM)能力<
<
10MLTE2×
10M(2*2SIMO)能力】
【10MHSPA+(16QAM+DC)能力和10MLTE2×
10M(2*2SIMO)接近】
上行DC能力,多数终端/设备厂商没有明确支持计划,不应列入实际比较
下图FDD20M能力图经过指数变形,不做参考或受CAT3不做参考
总体看,
LTE在10M频段无线条件下,单用户峰值速率与HSPA+持平,
LTE在10M频段资源以上时,单用户峰值速率要大于HSPA+,LTE有OFDM/MIMO优势。
但是HSPA+也有其优点:
3GPP定义了不同的最大速率编码.HSDPA的编码效率非常接近1(~0.98)。
相对的,LTE下行最大编码效率仅接近0.88。
不过反过来看,也可以认为LTE峰值速率的编码保护效果更好,保证在更大的范围内、更复杂的无线环境下LTE都可以其峰值速率
2)HSPA+小区吞吐量
实际环境中,用户能够满足“良好的”无线信号条件,从而获得峰值速率的可能性是很小的。
因此,对比LTE和HSPA+性能的最佳指标是小区平均吞吐率或者小区频谱效率。
小区平均吞吐率比较情况如下:
⏹即使采用MIMO技术,同等5M频段无线条件下:
小区下行吞吐量:
LTE与HSPA+相比,多38%
LTE与HSPA+相比,多94%
⏹如果采用10M频段进行比较,
由于HSPA+的上行DC能力不明确,所以上行吞吐量的差距会接近180%,
3)HSPA+MIMO引入利弊
HSPA+对于3GPP运营商,其吸引力在于不改变现有网络结构;
64QAM/FractionDPCH/快速休眠/PCH到DCH的直接跃迁/DualCell下行双载波合并等提升技术,都有可能通过软件升级达到HSPA+的提升效果;
但是MIMO要求硬件置换,3GPP运营商(如AT&
T等)对此非常谨慎。
主要基于如下考虑:
支持MIMO的条件:
⏹MIMO需要2个功放在2个独立的信道中传输
⏹单个或一对业务流的建立需要来自基于UE支持能力的反馈
⏹2x2DoubleTransmit自适应天线阵列MIMO:
闭环single-stream(CLSSorTxAA)+dualstreamwith空分复用(DTxAA)
⏹UEcat15/16MIMOand17/18MIMOor64QAM
⏹UEcat19/20MIMO&
64QAMpendingUEavailability
MIMO引入的利弊:
⏹MIMOTxAAG-Rake可明显改善小区吞吐量
⏹非MIMO终端在STTD模式下,HSDPA性能下降15%;
特别是,当UE关闭均衡器功能时,性能会有更加明显的下降~40%
天线数目和UE接收机类型对HSDPA容量影响,如下图示
可以利用“虚拟天线矩阵技术”进行改进,但是会非常复杂,如下图示
MIMO的替代方案:
(1)双小区HSDPA(Rel8DC-HSDPA)
⏹通过跨载波的联合Mac-hs调度,将HSDPA用户下行业务同时以F1&
F2承载
⏹F1与F2为同一NodeB下同扇区中的两个异频逻辑小区:
Rel8中下行F1与F2须
⏹为相邻载波(Rel9扩展至不同频段)
⏹以TTI为单位统筹分配双载波上的功率和码字资源,以优化系统性能
(2)DC-HSDPA的性能小结
⏹在不增加基站硬件的同时,无需借助复杂的UE接收机类型,即可显著
⏹提升用户最大峰值速率(从21Mbps->
42Mbps)
⏹即使在小区边缘,也可获得更高的用户速率(相对于单载波,速率x2)
⏹可与R99~R7终端共载波,且不影响现有HSPA用户的性能
⏹明显改善HSDPA载波间负载平衡,提升系统整体资源利用率
(3)MIMO与DUALCELL的比较
⏹DC-HSDPA提供与MIMO相同的峰值速率,对2载波基站无额外硬件投入,而且避免了现网UE性能恶化的风险
⏹大多数客户考虑优先部署DC-HSPA,只有少量欧洲客户计划在Y10/11部署MIMO
综上所述,
从网络运营的角度来看,在WCDMAHSPA发展到一定时期之后通过软件升级的方式,可以平滑地升级到HSPA+,显著提高系统速率;
建议一DualCell作为MIMO的替代技术;
然后以10M频段资源为临界考虑,开始考虑是否引入MIMO技术进行硬件更替,同时权衡适时引入LTE。
3WCDMA/HSPA演进考虑:
【总结】
WCDMAHSPA技术的后向演进受到人们的广泛关注。
从核心技术、系统带宽、峰值速率、网络结构、多址技术、演进方式等方面比较,总体来说:
从HSPA升级到HSPA+以软件升级为主,演进较为平滑,在HSPA载频扩容到第3个载频时候;
考虑到需要替换硬件平台,HSPA+MIMO的引入需要慎重。
建议以DUALCELL作为技术替代;
暂缓MIMO硬件平台的替换问题。
建议HSPA/HSPA+在扩容到第3/第4载频的时候考虑是否引入MIMO,或者引入LTE;
在HPSA/HSPA+扩容到第4/第5载频的时候,需要择机引入LTE。
因为不仅从技术驱动因素(10M频段资源是LTE/HSPA+性能的平衡点,20M频段条件下LTE/HSPA+性能差异明显),还是运营商竞争因素和LTE成熟时间(中国移动TDLTE2012/2013)因素来看,20M频宽条件下,必须考虑LTE/LTE+引入和增加更换硬件平台。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WCDMA HSPA 向LTE的演进 LTE 演进
![提示](https://static.bdocx.com/images/bang_tan.gif)