Resource Allocation and Management Unit

Reading various LTE specification, you will see many terms which seems to be related to resource allocation but looks very confusing. At least you have to clearly understand the following units.

Resource Element(RE) : The smallest unit made up of 1 symbol x 1 subcarrier.
Resource Element Group (REG) : a group of 4 consecutive resource elements. (resource elements for reference signal is not included in REG)
Control Channel Element (CCE) : a group of 9 consective REG
Aggregation Level : a group of 'L' CCEs. (L can be 1,2,4,8)
RB (Resource Block) : I think everybody would know what this is. This is a unit of 84 resource elements which is 12 subcarrier by 7 symbols (This is with normal Cylic Prefix which is used in most of the LTE deployment. If it is with Extended Cyclic Prefix, the number of symbols within a slot become 6 and the number of resource elements in a single RB become 72).
RBG (Resource Block Group) : This is a unit comprised of multiple RBs. How many RBs within one RBG differs depending on the system bandwidth. (Refer to RB Size allocation for each System Bandwidth for the details)

The list splits into two families, and the rest of this page keeps them apart. REG, CCE and aggregation level describe the control region, where the PDCCH lives. RB and RBG describe the data region, where the PDSCH lives. The RE is the only unit the two families share.

Order of Numbering Units

The control units are built in a fixed order, and each step depends on the one before it. The eNB cannot count CCEs before it knows how many REGs are left. It cannot count REGs before it knows how many symbols the control region has.

Following is the overall procedure to number from RE to Aggregation Level.

i) determine the number of OFDM symbols for control region
ii) number each REs
iii) group REs into REG and number each of the REGs
iv) group REGs into CCE and number each of the CCEs
v) group CCE according to Aggregation level (let's call this group as a 'CCE Bundle').
vi) Assign one CCE Bundle to one PDCCH

Step i comes from PCFICH. The CFI it carries gives the number of control symbols, 1 to 3 in most bandwidths. Everything after step i scales with that number, so a wrong CFI decode shifts every REG and CCE index the UE computes.

Step iii has one more job that the list does not show. PCFICH and PHICH also use REGs, and they take theirs first. 36.211 clause 6.8.1 builds the CCEs only from the REGs not assigned to PCFICH or PHICH. The number of CCEs is that REG count divided by 9, rounded down.

Let's put numbers on it for 10 MHz, which has 50 RBs. Take CFI = 3, normal CP, one or two CRS ports and PHICH Ng = 1. The first symbol has 2 REGs per RB, because the CRS takes 2 of every 6 REs there. The second and third symbols have 3 REGs per RB. That gives 100 + 150 + 150 = 400 REGs. PCFICH takes 4 REGs, and 7 PHICH groups take 3 REGs each, so 375 REGs remain. Divided by 9, that is 41 CCEs for the whole subframe.

CFI comes first : the number of control symbols fixes how many REGs exist at all.
PCFICH and PHICH are served before PDCCH : their REGs are removed before the CCEs are counted.
One CCE is 9 REGs, which is 36 REs : with QPSK that is 72 bits, which 36.211 Table 6.8.1-1 lists for PDCCH format 0.
41 CCEs at 10 MHz : with CFI 3, one or two CRS ports and Ng = 1, the subframe has 41 CCEs to share among all PDCCHs.

Example

The two drawings below show the same CCE twice. One shows how the REGs are numbered and grouped. The other shows where those REGs actually go in the resource grid, and the two pictures look very different.

We use these units in hierachical manner depending on whether it is for control channel or data channel.

The drawing below is a column of REs in the first two control symbols. The labels on the right group the REs into REGs, nine REGs into a CCE, and two CCEs into one aggregation. The callout on the left points at a REG that is longer than the others.

A column of REs in symbols 0 and 1 grouped into REG n to REG n+17, with REG n to n+8 forming CCE n, REG n+9 to n+17 forming CCE n+1, and the two CCEs forming one aggregation at aggregation level 2

The logical hierarchy of the control region. Two CCEs of nine REGs each make one PDCCH at aggregation level 2.

REG n to REG n+8 form CCE n : REG n+9 to REG n+17 form CCE n+1 in the same way, so each CCE is nine consecutive REG numbers.
The two CCEs form Aggregation n : the right hand bracket marks the case of aggregation level 2.
A REG can span five REs : the callout marks a REG with a reference signal in the middle, which still holds only four usable REs.
The three rules at the top set the sizes : 4 REs per REG without the reference signal REs, 9 REGs per CCE, and 1, 2, 4 or 8 CCEs per aggregation.

The above illustration would look straightforward but may be a little bit misleading. You may think of the REG arrangement within a CCE is a kind of logical assignment, not physical assignement. The REG arrangement within a CCE is arranged in consecutive manner, but in real (physicall) allocation, the REGs in a CCE get permutated and scattered across the whole bandwidth and control channel symbol as illustrated below.

The REGs of CCE n on a logical column at the left, the 36.211 clause 6.8.5 text on quadruplet permutation in the middle, and a 72 subcarrier by 14 symbol grid at the right where the REGs of that CCE are scattered over the first two symbols

The physical placement of one CCE. Its nine REGs are consecutive in the numbering but spread over the whole band in the grid.

The grid is 1.4 MHz : the vertical axis runs from subcarrier 0 to 71, which is 6 RBs, and the horizontal axis runs over symbols 0 to 13.
The red box covers the first two symbols : that is the control region in this example, and the orange REGs of CCE n are spread from the bottom to the top of it.
The quoted text is 36.211 clause 6.8.5 : the block of symbol quadruplets is permuted before it is mapped, which is what scatters the REGs.

For further details of physical allocation of REG in control channel, refer to following links.

The scattering happens in three steps in 36.211 clause 6.8.5. First the quadruplets, one per REG, go through the same sub-block interleaver that 36.212 uses for bits. Then the result is cyclically shifted by the physical cell ID, so two neighbour cells scatter the same CCE differently. Finally the quadruplets are written into the free REGs, running through the control symbols at one frequency before moving up to the next.

For PDCCH, the hierachy would be : RE --> REG --> CCE --> Aggregation Level

==> I think a couple of example would give you more practical understanding.

Example 1 > a PDCCH transmission

i) The CCE index for a certain subframe = 4

ii) Aggregation Level is 2

iii) The subframe is sending DCI1 only

Resource Allocation : Network would allocate the DCI 1 spreaded over CCE4, CCE5.

Example 2 > a PDCCH transmission

i) The CCE index for a certain subframe = 4

ii) Aggregation Level is 2

iii) The subframe is sending DCI1, DCI 0

Resource Allocation : Network would allocate the DCI 1 spreaded over CCE4, CCE5 and allocate the DCI 0 spreaded over CCE6, CCE7.

Example 3 > a PDCCH transmission

i) The CCE index for a certain subframe = 4

ii) Aggregation Level is 2

iii) The subframe is sending DCI1, DCI 0 and DCI 3 (power control)

Resource Allocation : Network would allocate the DCI 1 spreaded over CCE4, CCE5 and allocate the DCI 0 spreaded over CCE6, CCE7 and allocate four CCE for DCI 3 but DCI 3 would be allocated to a common search space (not to a user specific search space).

For PDSCH, the heirachy would be RE --> RB --> RBG

==> This is pretty long story. Please refer to Resource Allocation Type

Numbering is logical, placement is physical : consecutive REG numbers inside a CCE end up far apart in the grid.
The cell ID changes the placement : the cyclic shift in 36.211 clause 6.8.5 makes neighbour cells spread their CCEs differently.
Two DCIs need two sets of CCEs : in Example 2 the DCI 1 and the DCI 0 each take their own two CCEs.
DCI 3 goes to the common search space : that search space only uses aggregation level 4 or 8, as the next section shows.

Where can a PDCCH sit inside the CCE list ?

The examples above start the DCI at CCE 4 and CCE 6, and that choice is not free. A PDCCH at aggregation level L can only start at a CCE index that the UE is going to check. Otherwise the UE never finds it, because it only blind decodes a small set of candidates.

36.213 clause 9.1.1 defines those candidates as search spaces. Table 9.1.1-1 of 36.213 gives the numbers the examples need.

In the UE specific search space, the UE checks 6 candidates at aggregation level 1, 6 at level 2, 2 at level 4 and 2 at level 8.
In the common search space, the UE checks 4 candidates at aggregation level 4 and 2 at level 8. When the subframe has at least 16 CCEs, the common search space covers CCE 0 to CCE 15.

Two consequences follow for the examples. First, a candidate at level L always starts at a CCE index that is a multiple of L. So at level 2, CCE 4 and CCE 6 are valid starting points, and CCE 5 is not. Second, the common search space has no level 1 or level 2. A DCI 3 therefore takes at least four CCEs, which is why Example 3 gives it four and not two.

The UE specific search space also moves. Its start in each subframe comes from a hash of the C-RNTI and the subframe number, so a UE does not find its PDCCH at the same CCE index in every subframe. The fixed CCE index 4 in the examples is a simplification of that.

One more note on the aggregation levels. The current 36.211 Table 6.8.1-1 lists a PDCCH format 4 with 16 CCEs. The legacy search spaces in 36.213 Table 9.1.1-1 still use only levels 1, 2, 4 and 8, so the list at the top of this page is complete for them.

Candidates start at multiples of L : at level 2 a PDCCH can start at CCE 4 or CCE 6, but not at CCE 5.
The common search space uses level 4 and 8 only : DCI 3, DCI 3A and broadcast scheduling always take at least four CCEs.
The common search space is CCE 0 to 15 : 16 CCEs when the subframe has that many, shared by every UE in the cell.
The UE specific start moves every subframe : it depends on the C-RNTI and the subframe number.

Reference

The control region units come from 36.211, and the search space rules come from 36.213.

[1] 36.211 : 3GPP - E-UTRA; Physical channels and modulation, v19.3.0. Clause 6.2.4 defines REGs, clause 6.8.1 CCEs and PDCCH formats, and clause 6.8.5 the mapping to resource elements.
[2] 36.213 : 3GPP - E-UTRA; Physical layer procedures, v19.4.0. Clause 9.1.1 and Table 9.1.1-1 define the PDCCH search spaces.