LTE-Advanced关键技术及标准化进展(转载)

摘要

LTE-Advanced作为4G的候选技术方案,是在LTE基础上的进一步增强。本文介绍了3GPP中LTE-Advanced的各个关键技术点及其标准化情况,包括载波聚合、多点协作传输、上下行MIMO传输以及中继等。

1 引言

2008年3月ITU-R发出通函,向各成员征集4G候选技术提案,正式启动了4G标准化工作,3GPP也展开了面向4G的研究工作,并于2008年6月完成了LTE-Advanced(以下简称LTE-A)技术的需求报告,2009年6月3GPP向ITU提交了技术描述文件,10月提交了自评估报告,完成了IMT-Advanced候选技术提交工作。LTE-A是LTE的平滑演进,与LTE R8保持后向兼容;支持多种覆盖场景,提供从宏蜂窝到室内场景的无缝覆盖;重点解决低速移动环境中的高速数据传输,包括进一步降低技术成本和能耗等;性能指标是系统带宽大于20 MHz,支持的下行峰值速率为1Gbit/s,频谱效率提高到30bit/s/Hz,上行峰值速率为500Mbit/s,频谱效率提高到15 bit/s/Hz。LTE-A系统将下行天线扩展到8×8,上行天线扩展到4×4,并且引入了载波聚合技术、中继技术和多点协作传输技术,以下总结了这些技术的标准化进展情况。

2 关键技术及标准化进展

(1)载波聚合技术

ITU IMT-Advanced要求系统的最大带宽不小于40MHz,考虑到现有的频谱分配方式和规划,很难找到足以承载IMT-Advanced系统带宽的整段频带,因此3GPP确定采用载波聚合的方式,聚合两个或更多的成员载波,从而解决LTE-A系统对频带资源的需求。载波聚合可以分为连续载波聚合和非连续载波聚合两种,连续频谱聚合可以简化基站和终端的配置,可以应用于如3.4~3.8GHz频段的频率分配,非连续频谱聚合有更强的频谱聚合灵活性,需要定义频谱聚合所支持的终端能力,以便将终端大小、成本和功率损耗降到最低。

3GPP自RAN1 #53次会议开始讨论载波聚合的相关内容,在RAN1 #54bis会议得出如下几点基本的结论:考虑到与LTE的兼容性,各个成员载波将采用LTE的设计,并最大占110个RB(20MHz);所有的成元载波都是与R8 LTE兼容的,但不排除对非后向兼容的成元载波的考虑;关于聚合带宽和上下行非对称,UE可能被配置为在上下行分别聚合不同数量、不同带宽的成元载波,而对于TDD,典型情况下,上下行的成员元载波数是相同的。

在这些基本结论的基础上,将MAC层聚合作为基准假设,即从UE角度每个调度的成员载波均有一个传输块和HARQ。对载波聚合中的下行控制信令PDCCH的设计,确定了一个PDCCH只在一个载波内传输,采用各载波分别编码的PDCCH设计方式,支持通过载波指示比特进行跨载波调度的方式。采用UE Specific的机制确定是否使用载波指示域(CIF),长度固定为3bit,位置在不同DCI格式下均是固定的,当DCI格式的大小相同时,使用显式的CIF支持跨载波的调度,当DCI格式的大小不同时,是否包含CIF需要进一步的讨论。

对于PCFICH的设计方式,每个成员载波有独立的控制区域大小,在有控制区域的载波上,重用Rel-8PCFICH的设计(调制、编码、映射)。关于跨载波调度情况下的控制区域指示问题,需要进一步的讨论。

对于PHICH的设计方式,重用R8中的PHICH物理传输,包括正交码的设计,调制,扰码序列,映射到REs的方法,PHICH只在发送UL grant的下行成员载波上传输,PHICH 资源映射原则:在没有载波指示域(CIF)的1:1 或者 Many:1 的DL和UL映射,重用 R8 映射。需要进一步讨论的问题有:不同载波是采用统一的PHICH资源还是分别采用不同的PHICH资源,在下行载波对上行载波是1对多的情况下,或者带有载波指示域的情况下,如何进行PHICH资源映射。

LTE-A支持最多5个下行成员载波的设计(未来考虑扩展到更多数目),对于PUCCH的设计方式,在没有PUSCH数据发送的时候,一个UE的所有Ack/Nack在PUCCH上发送,目前支持PUCCH映射到UE专用的一个上行成员载波上。每个UE在PUCCH上发送一个调度请求。支持至多是5个下行载波的周期CSI上报,CQI/PMI/RI的编码和映射延用R8的原则。需要进一步研究的问题有:是否支持多个上行载波同时发送Ack/Nack,以及Ack/Nack资源分配的确切方法。

载波聚合情况的上行功率控制,LTE-A中的上行功率控制范围与R8类似:在降低由邻区产生干扰的同时,主要对慢变信道进行补偿;PUSCH采用部分功率控制或者全信道损失补偿,PUCCH采用全信道损失补偿。LTE-A支持连续和非连续载波聚合下,载波专用的上行功率控制。

关于载波的类型,目前定义了“后向兼容载波”,“非后向兼容载波”,“扩展载波”,“UE下行载波集合”,“UE上行载波集合”等概念,后向兼容载波是LTE R8的终端可以接入的载波;非后向兼容载波是LTE R8不能接入的载波,由双工间隔的原因引起的非后向兼容载波可以作为独立的载波使用;扩展载波是不能作为独立载波使用的非后向兼容载波;在此基础上,高通提出载波Segment的概念,其与扩展载波的区别在于工作带宽和PDCCH传输的不同等,目前正在等待RAN4联络函的回复。考虑到终端PDCCH盲检测的负担,以及PHICH资源预留的数量和灵活性,多家公司建议定义PDCCH Monitoring Set的概念,即终端进行PDCCH检测的下行成员载波集合,但是需要考虑集合的具体定义,如何更新(频度)等都需要进一步的讨论。

(2)下行传输技术

LTE支持4×4天线的配置,LTE-A将SU-MIMO扩展到8×8配置的场景下,到目前为止,3GPP RAN1达成了一些关于LTE-A中SU-MIMO的8天线空间复用和发送分集有一些一致性的结论。

空间复用传输块的最大数目为2,每个传输块内有1个MCS域,每个传输块中有1bit的ACK/NACK用来作为评估的基准,码字到层的映射,4层以下(包括4层)重用LTE的映射方法,4层以上将LTE码字到层映射的方法作为基准。采用基于码本的预编码反馈作为基本的工作假设,是否采用Layer Shifting以及控制信令的细节等还需要进一步讨论。对于8天线的发送分集方式,R10 UE在非MBSFN子帧中的PDCCH和PDSCH,重用R8中的2或4天线的分集方式,对于R10 UE在MBSFN子帧中的PDSCH分集方式需要进一步讨论。

LTE R8中的多用户MIMO,通过传输模式5半静态的配置用户处于多用户MIMO状态,并且每个用户只有一个layer,下行控制信令Format 1D和MU-MIMO的传输模式相关。总体来说,LTE R8中的多用户MIMO具有以下特点:

仅限于基于码本的预编码方式,采用的是SU-MIMO优化的码本,4发射天线配置的粒度是4比特。解调基于公共参考信号,编码信息是通过基站的下行分配信令指示的。由于没有与其共同调度终端相关的下行信令,限制了基于终端的干扰抑制/消除的有效性和灵活性。

反馈上报支持的模式有非周期Mode 3-1上报和周期Mode1-1和Mode 2-1上报,只支持宽带PMI预编码上报,这种反馈机制在相关性强的天线配置情况,也就是频率选择性弱的场景下更有用。并且只支持Rank1上报。

尽管R8标准中没有明确的限制在一个资源块上调度多于两个用户,实际中因为单个的功率偏置比特,最多只能同时调度两个用户。另外,每个用户限制接收一个Layer。

LTE-A将多用户MIMO进行了扩展,讨论的内容集中在:单用户和多用户的切换,是进行透明还是非透明的多用户MIMO(也就是用户是否知道自己配对的用户信息),反馈的增强方法(考虑基于CQI/RI/PMI的增强,或者可能的显式反馈方法),码本的增强方法,每个参与配对的MU-MIMO 的UE layer数,共同调度的MU-MIMO 终端数量等。目前,确定支持SU-MIMO和MU-MIMO之间的动态切换,即不需要RRC Reconfiguration的切换,其他问题还没有得出相应的具体结论。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结