CCE Index is the CCE number at which the control channel data (PDCCH) is allocated. Normally this index changes for each subframe, meaning that even the same PDCCH data (e.g, a PDCCH for the same UE) allocated in each subframe changes subframe by subframe. (If you are not familiar with what is CCE, refer to Resource Element Management section first.)

One of the most common situations where you have to care about this CCE index is when you change the system BW. Changing the system bandwidth in higher layer (L3) is very simple. You only have to change one IE in MIB, but if you are a protocol stack developer or test case developer who take care of all stack from L1 through L3, you have to calculate CCE index for each subframe and those index gets different for each bandwidth. But calculating CCE is not a simple procedure. Just outline of the calculation is as follows. Just try to have an idea on which parameters you need and how they are related to calculate CCE.

• CCE Index Calculation Procedure
• PDCCH Decoding/Blind Decoding on UE side
• Live Examples
• Why so complex ?
• Reference :

CCE Index Calculation Procedure

Followings are the brief summary of the procedures of calculating the CCE Index. (I would recommend you to refer to Ref [2] for further details and different way of explanation)

Step 1 : Figure out all the REs within the Control region (the first 1 or 2 or 3 OFDM symbols) that can be reserved for PDCCH allocation. (Note : item (iii), (iv) are only in the first OFDM symbol. Item (ii) is located in multiple OFDM symbols, but within the control region it is also located only in the first OFDM symbol. Refer to Downlink Frame Structure page for the details of each channel allocation in RB map)

RE's for PDCCH = Total Available RE's within control symbols    -------(i)

                       - Number of RE's used for reference signals   -------(ii)

                       - Number of RE's used in PHICH  -------------------(iii)           

                       - Number of RE's used in PCFICH ------------------(iv)

Step 2 : Figure out total number CCE's available for PDCCH.

total number CCE's available for PDCCH = (The Result of Step 1)/36, since 1 CCE = 36 REs

Step 3 : Number each of the CCEs from the result of Step 2. (Number starts from 0).

Step 4 : eNB decide CCE index according to following formula (Note : Depending on Aggregation Level(L), you will get the different number of consecutive CCEs for allocating one PDCCH. For example, if L is 1, 'i' can be only '0'. So you have only one CCE for the PDCCH. If L = 4, you will have for CCE index by plugging 0,1,2,3 into the variable 'i'. Then you will have four consecutive CCE index. It means one PDCCH will be spread over the four consecutive CCEs).

The CCE index formula of 36.213 clause 9.1.1, with each term named. Only two things in it change per subframe: Y_k, which carries the randomisation, and N_CCE,k, which is how much control region the scheduler gave itself that subframe.

• L : the aggregation level, and it appears twice. It divides N_CCE,k to give the number of starting positions, then multiplies the result again so the answer lands on an L-aligned boundary.
• N_CCE,k : the total number of CCEs in the control region of subframe k. It is not a constant, because the control region is one, two or three symbols wide and PHICH takes its share first.
• Y_k : the hashing term. For common search space it is simply 0, which is why the common space starts at CCE 0 in every subframe. For UE specific space it is the recursion Y_k = (A · Y_k-1) mod D, with A = 39827 and D = 65537.
• Y_-1 = n_RNTI : the recursion is seeded with the UE's own RNTI, which must be non-zero. Two UEs with different RNTIs therefore walk different sequences, and that is the whole point of the design.
• m and M^(L) : m counts the PDCCH candidates the UE has to try at this aggregation level, and M^(L) is how many there are. The table in the next section gives those numbers.
• i = 0 … L-1 : the offset inside one candidate. A candidate at aggregation level 4 occupies four consecutive CCEs, and i steps across them.
• k = ⌊n_s/2⌋ : the subframe number, derived from the slot number. The recursion advances once per subframe, not once per slot.

Following is an Example of CCE index calculation. First try calculating the values on your own according to the descriptions above (Step 4) and compare your result with my result (Excel Spreadsheet is also linked here). The cell in green is the parts that should be derived/calculated from other cells. (Note : In this example, I assumed the case where 100 CCEs are available. But in reality, there is no such a case where you can have 100 CCE. To have 100 CCEs, you need 3600 RE (=36 RE/CCE * 100 CCE). In case of 20 Mhz Bandwidth, CFI = 3. You have 3600 RE in Control Region, but you have remove those REs for Reference Signal, PCFICH and PHICH. So the available REs for CCE become less than 100 CCE. Refer to Ref [1] for the details of calculating the available CCEs)

(Click here to get excel spreadsheet)

For further details of the procedure, refer to TS 36.213 - 9.1.1 PDCCH Assignment Procedure.

One number in that formula has not been given a value yet, and the specification gives it in a table rather than a line. M^(L) is the number of PDCCH candidates the UE monitors at each aggregation level, and it differs between the two search spaces.

Two things in that table are worth carrying forward. The common search space uses only aggregation levels 4 and 8, so a UE never looks for a common PDCCH at level 1 or 2. The candidate counts add up to 6 in the common space and 16 in the UE specific space. That is where the blind decoding arithmetic of the next section comes from.

• The formula is deterministic, not random : given the RNTI, the subframe and N_CCE,k, both ends compute the same index. Nothing is signalled.
• N_CCE,k is the part that moves with configuration : change the bandwidth, the CFI or the PHICH setting and the divisor changes, so the same UE lands somewhere else.
• The RNTI seeds the whole sequence : Y_-1 = n_RNTI, so two UEs collide only occasionally rather than persistently.
• Aggregation level rounds the answer : multiplying by L at the end forces the index onto a multiple of L. A level 4 allocation therefore never starts at CCE 3.

Too complicated ? If you are not the person who has to implement this algorithm in your chipset, just try to understand the basic idea explained below.

PDCCH Decoding/Blind Decoding on UE side

UE has 'ALMOST' no information for decoding PDCCH. So UE has to try 'ALL' the possible tries to decode PDCCH. This is called 'Blind Decoding'.

For example, let's look into all the possible combinations to try for Common Search Space and assume the total space is 16 CCEs. Following is factors and number of combinations.

i) All the possible blocks assuming Aggregation Level  4 = 16 (CCE) / 4 (Aggregation Level) = 4 blocks

ii) All the possible blocks assuming Aggregation Level  8 = 16 (CCE) / 8 (Aggregation Level) = 2 blocks

iii) All the possible DCI formats supported for common space = assuming 2 (out of 0,1A,3,3A,1C based on TM)

----------------------------------------------------------------------------------------------

Total number of decoding tries = ( i + ii) x iii = (4 + 2) x 2 = 12

After all of these blind trials, UE checks CRC with all the possible RNTIs it can be applicable.

The two counts in that sum come straight from 36.213 Table 9.1.1-1 above. Common search space has 4 candidates at aggregation level 4 and 2 at level 8, which is the 4 and the 2 in lines i) and ii). Levels 1 and 2 do not appear because the common space does not use them.

• Blind decoding is bounded, not open ended : the candidate counts are fixed by the specification, so the UE knows before it starts exactly how many attempts it faces.
• The CRC is the only confirmation : a PDCCH carries no explicit addressing. The UE decodes a candidate, then checks whether the CRC unmasks with an RNTI it owns.
• The UE specific space costs more : 16 candidates against 6, across four aggregation levels rather than two, and the UE searches both every subframe.

Live Example of CCE Allocation

Following is a example of CCE index calculation (CCE Allocation for PDCCH) in real communication between UE and eNB simulator from Amarisoft Callbox. (This is the example with the case of BandWidth = 5Mhz,  CFI = 3, C_RNTI = 0x61)

A PDCCH allocation as the log viewer prints it. Each red-underlined PDCCH line carries cce_index=N/20, so the denominator is N_CCE,k and the numerator is the index the formula produced. The SFN column reads as frame.subframe, which is how one radio frame spreads down the page.

• The PDCCH lines are the ones to read : each says cce_index, L and dci, for example cce_index=12/20 L=4 dci=1a. The PDSCH and PUCCH lines between them are the data and the acknowledgement that follow from it.
• The denominator never changes here : every line reads /20, so this cell keeps 20 CCEs in its control region for the whole capture. That is N_CCE,k holding still while Y_k moves.
• L is 4 on every line : the scheduler kept one aggregation level throughout, which is what makes the pattern in the tables below readable at all.
• The SFN column is frame.subframe : 615.1 is subframe 1 of frame 615. The rows step through 615, 615.1, 615.2 and onward, so one screen covers most of a radio frame.
• RNTI 0x61 is the same throughout : one UE, one recursion. A second UE on the same cell would produce a different sequence of indices from the same formula.

Following is the CCE index from the log shown above and presented in a tabular form. See if you can find a kind of pattern.

One pattern in those tables is worth naming, because it is the formula showing through. Every CCE index in this capture is 0, 4, 8, 12 or 16, and no other value ever appears. That is not a coincidence of scheduling.

The reason is the floor division. With N_CCE,k = 20 and L = 4, the term ⌊N_CCE,k / L⌋ is 5, so the modulo can only return 0, 1, 2, 3 or 4. Multiplying by L turns those five values into 0, 4, 8, 12 and 16. The hashing term chooses which of the five the UE gets in a given subframe, and it can choose nothing else.

That also explains why the same index repeats across subframes. Five positions over ten subframes makes repetition certain. So 4 appearing twice in a row is what a pseudo-random sequence over five values looks like, not a fault in the log.

• Count the positions before reading the indices : ⌊N_CCE,k/L⌋ tells you how many starting points exist, and every index must be a multiple of L below that.
• Repeats are expected : five positions over ten subframes cannot avoid collisions with itself. An index appearing twice is normal.
• Change L and the whole grid changes : at L = 8 the same 20 CCEs give only two positions, 0 and 8. At L = 1 they give twenty.

Following is another presentation of CCE index allocation in tabular form. You will see 4 consecutive CCE allocation for each PDCCH. This is because AggregationLevel in this example is 4. The CCE Index calculated at each subframe indicates the first CCE number of the four consecutive CCEs.

Why so complex ?

When I first try to understand and configure CCE index at early phase of verification, the first question poping up in my mind was "Why is it designed in such a complicated manner to determine the CCE Index (Location of PDCCH allocation) ?".

Of course (and unfortunately) 3GPP specification never tell you "Why ?", it says only "What". I think you can get this "Why" part from various TDocs related to this issue. Following is from "2.1 Requirements of R1-072470" and blue part is my comments.

•Possibility for interference randomization between cells. A certain control channel should not persistently collide with one and the same control channel in a neighboring cell.  --> This is why we assign different CCE Index for every subframe.

•Possibility for interference coordination. By using different parts of the frequency spectrum in different cells for control signaling it should be possible to avoid/reduce inter-cell interference for the control channels.

•As seen from the UE, the CCE-to-RE mapping structure should be invariant to whether interference coordination is used or not. After the cell-search procedure, the UE does not know whether a cell is applying interference coordination or not but still needs to read system information from the “dynamic BCCH”. If the “dynamic BCCH” is mapped to the DL-SCH (or transmitted in a similar way as the DL-SCH), it must be possible to read the DL-SCH and associated control signaling without knowledge about any inter-cell coordination.

•Control signaling should utilize the full system bandwidth to exploit any frequency diversity (already agreed in RAN1). --> This is why the total number of RBs for the full system bandwidth is used as a parameters in the CCE index determination algorithm.

•Two symbols from the same CCE should be mapped to two in frequency neighboring REs in order to support SFBC as the diversity scheme (already agreed inRAN1).

Reference :

[1] PDCCH Dimensioning (LTE University)

[2] All about PDCCH and CCE allocation (Tayal's way to learn LTE)