载波聚合.docx

载波聚合.docx

《载波聚合.docx》由会员分享，可在线阅读，更多相关《载波聚合.docx（12页珍藏版）》请在冰豆网上搜索。

载波聚合

载波聚合（CarrierAggregation）

首先介绍几个基本概念

PrimaryCell（PCell）：

主小区是工作在主频带上的小区。

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

在切换过程中该小区被指示为主小区（见36.331的3.1节）

SecondaryCell（SCell）：

辅小区是工作在辅频带上的小区。

一旦RRC连接建立，辅小区就可能被配置以提供额外的无线资源（见36.331的3.1节）

ServingCell：

处于RRC_CONNECTED态的UE，如果没有配置CA，则只有一个ServingCell，即PCell；如果配置了CA，则ServingCell集合是由PCell和SCell组成（见36.331的3.1节）

CC：

ComponentCarrier；载波单元

DLPCC：

Downlink Primary ComponentCarrier；下行主载波单元

ULPCC：

Uplink Primary ComponentCarrier；上行主载波单元

DLSCC：

Downlink SecondaryComponentCarrier；下行辅载波单元

ULSCC：

Uplink SecondaryComponentCarrier；上行辅载波单元

一. 简介

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

载波聚合（CarrierAggregation,CA）是将2个或更多的载波单元（ComponentCarrier,CC）聚合在一起以支持更大的传输带宽（最大为100MHz）。

每个CC的最大带宽为20MHz。

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

∙        相同或不同带宽的CCs

∙        同一频带内，邻接或非邻接的CCs

∙        不同频带内的CCs 

图1：

载波聚合

     从基带（baseband）实现角度来看，这几种情况是没有区别的。

这主要影响RF实现的复杂性。

     CA的另一个动力来自与对异构网络（heterogeneousnetwork）的支持。

后续会在跨承载调度（cross-carrierscheduling）中对异构网络进行介绍。

     Rel-10中的所有CC都是后向兼容的（backward-compatible），即同时支持Rel-8的UE。

∙R10版本UE支持CA，能够同时发送和接收来自多个CC（对应多个servingcell）的数据

∙R8版本UE只支持在一个servingcell内，从一个CC接收数据以及在一个CC发送数据

  简单地做个比较：

原本只能在一条大道（cell或cc）上运输的某批货物（某UE的数据），现在通过CA能够在多条大道上同时运输。

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

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

二.  PCell/SCell/ServingCell/CC

     每个CC对应一个独立的Cell。

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

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

ServingCell可指代PCell也可以指代SCell。

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

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

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

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

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

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

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

图2：

CA配置举例（“P”代表PCC）

     与非CA的场景类似，通过SystemInformationBlockType2的ul-CarrierFreq和ul-Bandwidth字段，可以指定下行primarycarrier对应的上行primarycarrier（仅FDD需配置该字段）。

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

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

Ø DLCCs的个数根据该UE的DL聚合能力来配置

Ø ULCCs的个数根据该UE的UL聚合能力来配置

Ø 对于某个UE而言，配置的ULCCs数不能大于DLCCs数

Ø 在典型的TDD部署中，UL和DL的CC个数是一样的，并且不同的CC之间的uplink-downlinkconfiguration也应该是一样的。

但是特殊帧配置（specialsubframeconfiguration）可以不同。

（见36.211的4.2节）

     CA支持的频带见36.101的Table5.5A-1和Table5.5A-2。

对应RRC消息中如下字段：

BandParameters-r10:

:

=SEQUENCE{

  bandEUTRA-r10               INTEGER（1..64）,

  bandParametersUL-r10        BandParametersUL-r10              OPTIONAL,

  bandParametersDL-r10        BandParametersDL-r10              OPTIONAL

}

      每个CC能够支持的带宽见36.101的Table5.6-1。

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

     CA带宽类型（CABandwidthClass）见36.101的Table5.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之间的中心频率间隔必须是300kHz的整数倍。

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

图3：

不同CC间中心频率的间隔

   简单地做个比较：

还以上面的运输做类比，PCell相当于主干道，主干道只有一条，不仅运输货物，还负责与接收端进行交流，根据接收端的能力（UECapability）以及有多少货物要发（负载）等告诉接收端要在哪几条干道上收货以及这些干道的基本情况等（PCell负责RRC连接）。

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

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

发货端（eNodeB）才好按照对端（UE）的能力调度发货，否则接收端处理不过来也是白费！

（这里只是以下行为例，UE也可能为发货端）。

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

三. 跨承载调度（cross-carrierscheduling）

       在LTE-A中，跨承载调度的主要作用是在异构网络中为PDCCH提供ICIC（Inter-CellInterferenceCoordination）支持。

一个典型异构网络场景如下：

       一个macrocell和一个smallcell共享2个下行CC：

CC1和CC2。

smallcell的2个CC都在低传输功率下工作，macrocell的CC1在高传输功率工作，CC2在低传输功率工作。

macrocell在CC1上的传输对smallcell的CC1有很大的干扰。

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

图4：

一个典型的异构网络部署：

macrocell和smallcell共享2个CCs

   这里仅简单的介绍跨承载调度提出的原因，后续会在各个章节中详细介绍跨承载调度对协议的影响。

四. 对下行L1/L2控制信号的影响

     每个CC有独立的物理层（physicallayer），包括控制信令（controlsignaling）、调度（scheduling）和HARQ重传。

     每个CC有一个独立的controlregion。

     每个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，则在某一servingcell收到的PDCCH对应同一servingcell的PUSCH和PDSCH传输。

CrossCarrierSchedulingConfig-r10:

:

=     SEQUENCE{       对应某一SCell

  schedulingCellInfo-r10         CHOICE{

     own-r10                        SEQUENCE{               --Nocrosscarrierscheduling

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

     },

     other-r10                      SEQUENCE{             --Crosscarrierscheduling

         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次盲检）。

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

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

       与Rel-8相比可以看出，对于跨承载调度的CC而言，计算时增加了偏移量

。

其中c的值与CIF相同。

（详见36.213的9.1.1节）

图6：

多CCs的用户特定搜索空间（UE-specificsearchspaceformultipleCCs）

  关于搜索空间的详细介绍，可见我的博文《CCE介绍》和36.213的9.1.1节。

2. PCFICH

     对于支持CA的UE而言，每个CC都有各自的PCFICH，即不同的CC可能有不同大小的controlregion，也即PDSCH的起始symbol可能不同。

因此，原则上UE需要在它被调度的每个CC上接收PCFICH。

     与PDCCH一样，PCFICH也是在controlregion传输的，因此，跨承载调度场景中影响PDCCH的inter-cellinterference对于PCFICH也同样存在。

为了解决这个问题，Rel-10通过CrossCarrierSchedulingConfig的pdsch-Start-r10字段指定任意跨承载调度的PDSCH的起始OFDMsymbol，而不是通过解码对应CC上的PCFICH获得。

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

       越短的controlregion，就有越多的OFDMsymbol用于数据传输，反之亦然。

3. PHICH

     原则：

PHICH与对应的上行数据传输的ULGrant在同一个下行CC上传输。

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

     为了缓解这个问题，可以通过配置与PHICH在同一个DLcontrolregion传输的各个上行CC的DMRS参考信号的不同循环移位（cyclicshift）来偏移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-lossreferenceformeasurementsforuplinkpowercontrol，但是测量的频率降低，以便降低功率消耗。

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

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

       UE的激活/去激活机制基于MACcontrolelement和deactivationtimers的结合。

       基于MACCE的SCell激活/去激活操作是由eNodeB控制的，基于deactivationtimer的SCell激活/去激活操作是由UE控制。

    MACCE的格式：

LCID为11011，见下图：

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

       每个SCell有一个deactivationtimer，但是对应某个UE的所有SCell，deactivationtimer是相同的，并通过sCellDeactivationTimer字段配置（由eNodeB配置）。

该值可以配置成“infinity”，即去使能基于timer的deactivation。

       当在deactivationtimer指定的时间内，UE没有在某个CC上收到数据或PDCCH消息，则对应的SCell将去激活。

这也是UE可以自动将某SCell去激活的唯一情况。

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

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

（见36.213的4.3节）