LTE-A 载波聚合Carrier Aggregation介绍



载波聚合(Carrier Aggregation

首先介绍几个基本概念

Primary CellPCell):主小区是工作在主频带上的小区。UE在该小区进行初始连接建立过程,或开始连接重建立过程。在切换过程中该小区被指示为主小区36.3313.1

Secondary CellSCell):辅小区是工作在辅频带上的小区。一旦RRC连接建立,辅小区就可能被配置以提供额外的无线资源36.3313.1

Serving Cell处于RRC_CONNECTED态的UE,如果没有配置CA,则只有一个Serving Cell,即PCell;如果配置了CA,则Serving Cell集合是由PCellSCell组成36.3313.1

CCComponent Carrier;载波单元

DL PCC Downlink Primary Component Carrier下行主载波单元

UL PCC Uplink Primary Component Carrier上行主载波单元

DL SCC Downlink Secondary Component Carrier下行辅载波单元

UL SCC Uplink Secondary Component Carrier上行辅载波单元

一.简介

为了满足LTE-A下行峰速1 Gbps,上行峰速500 Mbps的要求,需要提供最大100 MHz的传输带宽,但由于这么大带宽的连续频谱的稀缺,LTE-A提出了载波聚合的解决方案。

载波聚合(Carrier Aggregation,CA)是将2个或更多的载波单元(Component Carrier,CC)聚合在一起以支持更大的传输带宽(最大为100MHz)。

每个CC的最大带宽为20 MHz

为了高效地利用零碎的频谱,CA支持不同CC之间的聚合(如图1

· 相同或不同带宽的CCs

· 同一频带内,邻接或非邻接的CCs

· 不同频带内的CCs


1:载波聚合

从基带(baseband)实现角度来看,这几种情况是没有区别的。这主要影响RF实现的复杂性。

CA的另一个动力来自与对异构网络(heterogeneous network)的支持。后续会在跨承载调度(cross-carrier scheduling)中对异构网络进行介绍。

Rel-10中的所有CC都是后向兼容的(backward-compatible),即同时支持Rel-8UE

  • R10版本UE支持CA,能够同时发送和接收来自多个CC(对应多个serving cell)的数据
  • R8版本UE只支持在一个serving cell内,从一个CC接收数据以及在一个CC发送数据

简单地做个比较:原本只能在一条大道(cell或cc)上运输的某批货物(某UE的数据),现在通过CA能够在多条大道上同时运输。这样,某个时刻可以运输的货物量 (throughput)就得到了明显提升。每条大道的路况可能不同(频点、带宽等),路况好的就多运点,路况差的就少运点。

二.PCell / SCell / Serving Cell / CC

每个CC对应一个独立的Cell。配置了CAUE1PCell和至多4SCell相连(见36.3316.4节的maxSCell-r10UEPCell和所有SCell组成了该UEServing Cell集合(至多5个,见36.3316.4节的maxServCell-r10Serving Cell可指代PCell也可以指代SCell

PCellUE初始接入时的cell,负责与UE之间的RRC通信。SCell是在RRC重配置时添加的,用于提供额外的无线资源。

PCell是在连接建立(connection establishment)时确定的;SCell是在初始安全激活流程(initial security activation procedure)之后,通过RRC连接重配置消息RRCConnectionReconfiguration添加/修改/释放的。

每个CC都有一个对应的索引,primary CC索引固定为0,而每个UEsecondary CC索引是通过UE特定的RRC信令发给UE(见36.3316.2.2节的sCellIndex-r10

某个UE聚合的CC通常来自同一个eNodeB且这些CC是同步的。

当配置了CAUE在所有的Serving Cell内使用相同的C-RNTI

CAUE级的特性,不同的UE可能有不同的PCell以及Serving Cell集合。


2CA配置举例(“P”代表PCC

与非CA的场景类似,通过SystemInformationBlockType2ul-CarrierFrequl-Bandwidth字段,可以指定下行primary carrier对应的上行primary carrier(仅FDD需配置该字段)。这样做的目的是无需明确指定,就知道通过下行传输的某个UL grant与哪个一上行CC相关。

CC的配置需要满足如下要求:

Ø DL CCs的个数根据该UEDL聚合能力来配置

Ø UL CCs的个数根据该UEUL聚合能力来配置

Ø 对于某个UE而言,配置的UL CCs数不能大于DL CCs

Ø 在典型的TDD部署中,ULDLCC个数是一样的,并且不同的CC之间的uplink-downlink configuration也应该是一样的。但是特殊帧配置(special subframe configuration)可以不同。(36.2114.2)

CA支持的频带见36.101Table 5.5A-1Table 5.5A-2。对应RRC消息中如下字段:


BandParameters-r10 ::= SEQUENCE {

bandEUTRA-r10 INTEGER (1..64),

bandParametersUL-r10 BandParametersUL-r10 OPTIONAL,

bandParametersDL-r10 BandParametersDL-r10 OPTIONAL

}

每个CC能够支持的带宽见36.101Table 5.6-1。对应RRC消息RadioResourceConfigCommonSCell-r10dl-Bandwidth-r10ul-Bandwidth-r10字段。

CA带宽类型(CA Bandwidth Class)见36.101Table 5.6A-1。对应RRC消息中如下字段:

CA-MIMO-ParametersDL-r10 ::= SEQUENCE {

ca-BandwidthClassDL-r10 CA-BandwidthClass-r10,230)"> supportedMIMO-CapabilityDL-r10 MIMO-CapabilityDL-r10 OPTIONAL

}

CA-BandwidthClass-r10 ::= ENUMERATED {a,b,c,d,e,f,...}

连续的CCs之间的中心频率间隔必须是300 kHz的整数倍。这是为了兼容Rel-8100 kHz frequency raster,并保证子载波的15 kHz spacing,从而取的最小公倍数(详见36.3005.5)。


3:不同CC间中心频率的间隔


简单地做个比较:还以上面的运输做类比,PCell相当于主干道,主干道只有一条,不仅运输货物,还负责与接收端进行交流,根据接收端的能力(UE Capability)以及有多少货物要发(负载)等告诉接收端要在哪几条干道上收货以及这些干道的基本情况等(PCell负责RRC连接)。SCell相当于辅干道,只负责运输货物。

接收端需要告诉发货端自己的能力,比如能不能同时从多条干道接收货物,在每条干道上一次能接收多少货物等(UE Capability)。发货端(eNodeB)才好按照对端(UE)的能力调度发货,否则接收端处理不过来也是白费!(这里只是以下行为例,UE也可能为发货端)。

因为不同的干道还可能运输另一批货物(其它UE的数据),不同的货物需要区分开,所以在不同的干道上传输的同一批货物(属于同一个UE)有一个相同的标记(C-RNTI)。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 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)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结