LTE载波聚合

首先介绍几个基本概念Primary Cell（PCell）：主小区是工作在主频带上的小区。

UE在该小区进行初始连接建立过程，或开始连接重建立过程。

在切换过程中该小区被指示为主小区（见36.331的3.1节）Secondary Cell（SCell）：辅小区是工作在辅频带上的小区。

一旦RRC连接建立，辅小区就可能被配置以提供额外的无线资源（见36.331的3.1节）Serving Cell：处于RRC_CONNECTED态的UE，如果没有配置CA，则只有一个S erving Cell，即PCell；如果配置了CA，则S erving Cell集合是由PCell和SCell组成（见36.331的3.1节）CC：Component 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-8的UE。

∙R10版本UE支持CA，能够同时发送和接收来自多个CC（对应多个serving cell）的数据∙R8版本UE只支持在一个serving cell内，从一个CC接收数据以及在一个CC发送数据简单地做个比较：原本只能在一条大道（cell或cc）上运输的某批货物（某UE的数据），现在通过CA能够在多条大道上同时运输。

这样，某个时刻可以运输的货物量（throughput）就得到了明显提升。

每条大道的路况可能不同（频点、带宽等），路况好的就多运点，路况差的就少运点。

二.PCell / SCell / Serving Cell / CC每个CC对应一个独立的Cell。

配置了CA的UE与1个PCell和至多4个SCell相连（见36.331的6.4节的maxSCell-r10）。

某UE的PCell和所有SCell组成了该UE的Serving Cell集合（至多5个，见36.331的6.4节的maxServCell-r10）。

Serving Cell可指代PCell也可以指代SCell。

PCell是UE初始接入时的cell，负责与UE之间的RRC通信。

SCell是在RRC重配置时添加的，用于提供额外的无线资源。

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

每个CC都有一个对应的索引，primary CC索引固定为0，而每个UE的secondary CC索引是通过UE特定的RRC信令发给UE的（见36.331的6.2.2节的sCellIndex-r10）。

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

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

CA是UE级的特性，不同的UE可能有不同的PCell以及Serving Cell集合。

图2：CA配置举例（“P”代表PCC）与非CA的场景类似，通过SystemInformationBlockType2的ul-CarrierFreq和ul-Bandwidth字段，可以指定下行primary carrier 对应的上行primary carrier（仅FDD需配置该字段）。

这样做的目的是无需明确指定，就知道通过下行传输的某个UL grant与哪个一上行CC相关。

CC的配置需要满足如下要求：Ø DL CCs的个数根据该UE的DL聚合能力来配置Ø UL CCs的个数根据该UE的UL聚合能力来配置Ø 对于某个UE而言，配置的UL CCs数不能大于DL CCs数Ø 在典型的TDD部署中，UL和DL的CC个数是一样的，并且不同的CC之间的uplink-downlink configuration也应该是一样的。

但是特殊帧配置（special subframe configuration）可以不同。

(见36.211的4.2节)CA支持的频带见36.101的Table 5.5A-1和Table 5.5A-2。

对应RRC消息中如下字段：BandParameters-r10 ::= SEQUENCE {bandEUTRA-r10 INTEGER (1..64),bandParametersUL-r10 BandParametersUL-r10 OPTIONAL,bandParametersDL-r10 BandParametersDL-r10 OPTIONAL}每个CC能够支持的带宽见36.101的Table 5.6-1。

对应RRC消息RadioResourceConfigCommonSCell-r10的dl-Bandwidth-r10和ul-Bandwidth-r10字段。

CA带宽类型（CA Bandwidth Class）见36.101的Table 5.6A-1。

对应RRC消息中如下字段：CA-MIMO-ParametersDL-r10 ::= SEQUENCE {ca-BandwidthClassDL-r10 CA-BandwidthClass-r10,supportedMIMO-CapabilityDL-r10 MIMO-CapabilityDL-r10 OPTIONAL}CA-BandwidthClass-r10 ::= ENUMERATED {a, b, c, d, e, f, ...}连续的CCs之间的中心频率间隔必须是300 kHz的整数倍。

这是为了兼容Rel-8的100 kHz frequency raster，并保证子载波的15 kHz spacing，从而取的最小公倍数（详见36.300的5.5节）。

图3：不同CC间中心频率的间隔简单地做个比较：还以上面的运输做类比，PCell相当于主干道，主干道只有一条，不仅运输货物，还负责与接收端进行交流，根据接收端的能力（UE Capability）以及有多少货物要发（负载）等告诉接收端要在哪几条干道上收货以及这些干道的基本情况等（PCell负责RRC连接）。

SCell相当于辅干道，只负责运输货物。

接收端需要告诉发货端自己的能力，比如能不能同时从多条干道接收货物，在每条干道上一次能接收多少货物等（UE Capability）。

发货端（eNodeB）才好按照对端（UE）的能力调度发货，否则接收端处理不过来也是白费！（这里只是以下行为例，UE也可能为发货端）。

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

三. 跨承载调度（cross-carrier scheduling）在LTE-A中，跨承载调度的主要作用是在异构网络中为PDCCH提供ICIC（Inter-Cell Interference Coordination）支持。

一个典型异构网络场景如下：一个macro cell和一个small cell共享2个下行CC：CC1和CC2。

small cell的2个CC都在低传输功率下工作，macro cell的CC1在高传输功率工作，CC2在低传输功率工作。

macro cell在CC1上的传输对small cell的CC1有很大的干扰。

因此，在small cell上，使用CC2上的PDCCH来跨承载调度传输在CC1上的数据是有好处的。

图4：一个典型的异构网络部署：macro cell和small cell共享2个CCs 这里仅简单的介绍跨承载调度提出的原因，后续会在各个章节中详细介绍跨承载调度对协议的影响。

四. 对下行L1/L2控制信号的影响每个CC有独立的物理层(physical layer)，包括控制信令（control signaling）、调度（scheduling）和HARQ重传。

每个CC有一个独立的control region。

每个CC有一个独立的DL-SCH或UL-SCH。

1. PDCCH如果不支持跨承载调度，与Rel-8一样，每个下行CC上的PDCCH携带的信息对应同一个CC的下行资源分配（DCI）或上行资源分配（UCI）。

如果支持跨承载调度，则允许一个CC上的PDCCH调度在另一个CC上传输的资源。

即PDCCH在一个CC上传输，而对应的PDSCH或PUSCH在另一个CC上传输。

图5：非跨承载调度与跨承载调度跨承载调度是通过RRC信令（是否存在crossCarrierSchedulingConfig-r10字段）并基于UE的每个CC配置的（即每个CC可独立地配置是否使能跨承载调度以及在其它哪个CC上调度）。

如果支持跨承载调度，会在PDCCH的起始处插入一个CIF字段，用于指定该PDCCH对应哪个CC。

是否存在CFI字段是通过CrossCarrierSchedulingConfig-r10的cif-Presence-r10字段来控制的。

注意：（1）CIF只存在于UE-specific搜索空间的PDCCH中，公共搜索空间的PDCCH是不存在CIF的。