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的。

（2）支持跨承载调度与否，会导致DCI格式有所不同，UE盲检时应根据具体的情况予以区分。

在某一CC上传输的数据，UE仅会在一个CC（同一个CC或跨承载调度时不同的CC）上收到对应的PDCCH。

如果支持跨承载调度，UE通过接收到的RRC消息CrossCarrierSchedulingConfig-r10的schedulingCellId-r10字段，知道需要在schedulingCellId-r10对应的CC上盲检另一SCell的PDCCH。

为了简单，CIF的值与RRC消息SCellToAddMod-r10中的sCellIndex-r10值是一致的。

如果没有配置CIF，则在某一serving cell收到的PDCCH对应同一serving cell的PUSCH和PDSCH传输。

CrossCarrierSchedulingConfig-r10 ::= SEQUENCE { 对应某一SCell

schedulingCellInfo-r10 CHOICE {

own-r10 SEQUENCE { -- No cross carrier scheduling

cif-Presence-r10 BOOLEAN 是否存在cross-carrier

},

other-r10 SEQUENCE { -- Cross carrier scheduling

schedulingCellId-r10 ServCellIndex-r10, 在该Cell上接收本SCell的PDCCH

pdsch-Start-r10 INTEGER (1..4) 指定在该SCell传输的PDSCH的起始symbol

}

}

}

至此（RRCConnectionReconfiguration配置之后），UE已经知道应该在哪些CC上盲检PDCCH，以及这些PDCCH对应哪些CC。

当配置CA，UE需要进行的盲检次数最多为 44 + 32 * numOfSCell（PCell需要44次盲检，而SCell不需要盲检公共搜索空间，

因此只需要做32次盲检）。

如果没有配置跨承载调度，每个Serving Cell的搜索空间与Rel-8是一致的。

如果配置了跨承载调度，搜索空间的定义如下：

与Rel-8相比可以看出，对于跨承载调度的CC而言，计算时增加了偏移量。其中c的值与CIF相同。（详见36.213

的9.1.1节）

图6：多CCs的用户特定搜索空间（UE-speci?c search space for multiple CCs）关于搜索空间的详细介绍，可见我的博文《CCE介绍》和36.213的9.1.1节。

2. PCFICH对于支持CA的UE而言，每个CC都有各自的PCFICH，即不同的CC可能有不同大小的control region，也即PDSCH 的起始symbol可能不同。因此，原则上UE需要在它被调度的每个CC上接收PCFICH。

与PDCCH一样，PCFICH也是在control region传输的，因此，跨承载调度场景中影响PDCCH的inter-cell interference对于PCFICH也同样存在。为了解决这个问题，Rel-10通过CrossCarrierSchedulingConfig的pdsch-Start-r10字段指定任意跨承载调度的PDSCH的起始OFDM symbol，而不是通过解码对应CC上的PCFICH获得。

该机制并不妨碍eNodeB动态改变每个CC的control region的大小（虽然在许多异构网络场景中，为了实现ICIC，通常会配置一个相对静态的control region大小）。

越短的control region，就有越多的OFDM symbol用于数据传输，反之亦然。

3. PHICH原则：PHICH与对应的上行数据传输的UL Grant在同一个下行CC上传输。

因此在CA中，一个DL CC可能要携带多个PHICH，从而增大了PHICH 冲突的可能性（因为PHICH索引是由对用的PUSCH的最低PRB决定的，对于多个UL CC可能是相同的）。

为了缓解这个问题，可以通过配置与PHICH在同一个DL control region传输的各个上行CC的DMRS参考信号的不同循环移位(cyclic shift)来偏移PHICH索引。

另外，eNodeB也可以通过在调度时让不同CC选择不同的上行资源起始PRB，从而避免冲突。

五、激活/去激活机制（Activation/Deactivation）（详见36.300的11.2节、36.321的5.13节以及36.213的4.3节）

为了更好地管理配置了CA的UE的电池消耗，LTE提供了SCell的激活/去激活机制（不支持PCell的激活/去激活）。

当SCell激活时，UE在该CC内1）发送SRS；2）上报CQI/PMI/RI/PTI；3）检测用于该SCell和在该SCell上传输的PDCCH。

当SCell去激活时，UE在该CC内 1）不发送SRS；2）不上报CQI/PMI/RI/PTI；3）不传输上行数据（包含pending的重传数据）；4）不检测用于该SCell和在该SCell上传输的PDCCH；5）可以用于path-loss reference for measurements for uplink power control，但是测量的频率降低，以便降低功率消耗。

重配消息中不带mobility控制信息时，新添加到serving cell的SCell初始为“deactivated”；而原本就在serving cell集合中SCell （未变化或重配置），不改变他们原有的激活状态。

重配消息中带mobility控制信息时（例如handover），所有的SCell均为“deactivated”态。

UE的激活/去激活机制基于MAC control element和deactivation timers的结合。

基于MAC CE的SCell激活/去激活操作是由eNodeB控制的，基于deactivation timer的SCell激活/去激活操作是由UE控制。 MAC CE的格式：LCID为11011，见下图：

Bit设置为1，表示对应的SCell被激活；设置为0，表示对应的SCell被去激活。

每个SCell有一个deactivation timer，但是对应某个UE的所有SCell，deactivation timer是相同的，并通过sCellDeactivationTimer字段配置（由eNodeB配置）。该值可以配置成“infinity”，即去使能基于timer的deactivation。

当在deactivation timer指定的时间内，UE没有在某个CC上收到数据或PDCCH消息，则对应的SCell将去激活。这也是UE可以自动将某SCell去激活的唯一情况。

当UE在子帧n收到激活命令时，对应的操作将在n+8子帧启动。

当UE在子帧n收到去激活命令或某个SCell的deactivation timer超时，除了CSI报告对应的操作（停止上报）在n+8子帧完成外，其它操作必须在n+8子帧内完成。(见36.213的4.3节)