http://paul.wad.homepage.dk/LTE/lte_resource_grid.html http://paul.wad.homepage.dk/LTE/lte_resource_grid.html http://paul.wad.homepage.dk/LTE/pdsch_calc.html?duplex_mode=tdd&tdd_ul_dl_cfg=2&tdd_spec_subf_cfg=6&bw=3&cp=ext&n _tx_ports=2&cfi=3&subframe=0&modulation=64qam&prb_alloc_slot0=all http://paul.wad.homepage.dk/LTE/index.

html

LTE Quick Reference

Go Back To Index Home : www.sharetechnote.com

RB Size allocation for each System Bandwidth For Resource Allocation Type 0 which is the most common resource allocation type, there is a rules for DL_RB setting if if if if if if System System System System System System BW BW BW BW BW BW = = = = = = 1.4 M, it should be multiples of 1 (1 x n) 3 M, it is should be multiples of 2 (2 x n) 5 M, it should be multiples of 2 (2 x n) 10 M,it should be multiples of 3 (3 x n) 15 M, it should be multiples of 4 (4 x n) 20 M, it should be multiples of 4 (4 x n)

This rule is derived from the Resource Block Group(RBG) size for each bandwidth, and the RBG size for system bandwidth is shown in TS 36.213 Table 7.1.6.1-1. (Number of DL RB should should be the multiples of RBG for the corresponding system bandwidth) * Reference for additional restriction and details : TS 36.104 Table 5.2.1 for DL (Number of RBs for each System BW), TS 36.211 Section 5.3.3 for UL (UL_RB = 2^a x 3^b x 5^c) Possible Number of RBs for UL : (Due to the rules stated in TS 36.211 Section 5.3.3. You can only have following numbers which can be used for UL) 1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36,40,45,48,50,54,60,64,72,75,80,81,90,96,100

LTE Quick Reference

Resource Allocation and Management Unit

Go Back To Index

Home : www.sharetechnote.com

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. i) Resource Element(RE) : The smallest unit made up of 1 symbol x 1 subcarrier. ii) Resource Element Group (REG) : a group of 4 consecutive resource elements. (resource elements for reference signal is not included in REG) iii) Control Channel Element (CCE) : a group of 9 consective REG iv) Aggregation Level - a group of 'L' CCEs. (L can be 1,2,4,8) v) RB (Resource Block) : I think everybody would know what this is. This is a unit of 72 resource elements which is 12 subcarrier by 6 symbols. vi) 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) We use these units in hierachical manner depending on whether it is for control channel or data channel.

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 two 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

LTE Quick Reference

PHICH/PHICH Group

Go Back To Index

Home : www.sharetechnote.com

PHICH stands for Physical channel HybridARQ Indicator Channel. Simply put, it is a secially designed downlink only channel which carries ACK or NACK for the PUSCH received by the network. Uplink case they just used PUCCH for carrying ACK/NACK for each PDSCH it recieved. Why don't we use PDCCH for ACK/NACK on network side. Good topic for you to think over -:) PHICH is carried by the first symbol of each subframe. (It is located in the same symbol as PCFICH). One PHICH is carried by multiple REG. Multiple PHICH can be carried by the same set of REG and these multiple PHICH being carried by the same REGs are called PHICH group. These multiple PHICHs are multiplexed by orthogonal codes. Therefore, to indentify a specific PHICH we need to know PHICH group number and orthogonal code index. In some (many ?) cases, mutiple PHICH can be mapped to a same set of resource elements and this group of PHICH being carried by the same set of resource element is called PHICH Group. (Why we have to carry multiple PHICH on a same set of resource elements ? Another good items for you to think -:) ). When some "multiple things" are carried by the same physical resources, we call the multiple things being "multiplexed". So we can say a group of PHICH is being 'multiplexed' onto a set of resource elements. When you multiplex something, you always have to think about how to "de-multiplex" them. It means that you have to multiplex somethings in such a way that they can be easily separated into individual things. If you multiplex things and those things cannot be demultiplexed, it is called a garbage -:). One of the most common way of multiplexing in wireless communication would be to use "orthogoal sequences". (You may remember how they multplexed multiple set of data in CDMA or WCDMA). PHICH multiplexing also uses the same method, meaning they are multiplexed with a set of predefined orthogonal sequences. The set of orthogonal sequence defined in 3GPP 36.211("6.9 Physical hybrid ARQ indicator channel") is as follows.

You may notice that the PHICH spreading factor for 'Extended cyclic prefix' is half of the one for 'Normal cyclic prefix'. As a summary, I will put down the definition of PHICH and PHICH group is defined in 3GPP 36.211 "6.9 Physical hybridARQ indicator channel" as follows.

You would quickly notice that number of PHICH group is twice as many for extended cyclic prefix as the one for normal cyclic prefix. You would see that to calculate the N_group_PHICH you should know Ng value and the specification says the Ng value comes from higher layer. In this case, the higher layers means "MIB (Master Information Block)". MIB has an IE(information element) called "phich-Resource" as shown below. This IE represents Ng.

How many PHICHs can be carried by one PHICH group ? Maximum 8 PHICHs can be multiplexed into a PHICH group when we use normal CP and Maximum 4 PHICHs can be multiplexed into a PHICH when we use the extended CP. Zero PHICH in a PHICH group is also allowed. How many PHICH groups can be supported by a system bandwidth ? This can be determined by the system bandwidth (N_RB) and a special parameter called Ng. These N_RB and Ng value is carried by MIB as shown above. With Ng and the N_DL_RB (maximum number of RB for a system bandwidth), you can calculate the N_group_PHICH as in the following table. N_RB \ Ng 6 (1.4 Mhz) 15 (3 Mhz) 25 (5 Mhz) 50 (10 Mhz) 75 (15 Mhz) 100 (20 Mhz) 1 1 1 2 2 3 1/6 1 1 2 4 5 7 1/2 1 2 4 7 10 13 1 2 4 7 13 19 25 2

Each PHICH in a PHICH group is mapped to each UE. How many REG would be required to carry one PHICH ? To figure this out, we have to go through several steps and do some mental calculation. i) ACK and NACK is encoded by 3 bits (111 for ACK, 000 for NACK). iii) According to Table 6.9.1-2 of 36.211, each bit of PHICH is spreaded by 4 bits (SF=4) when we use 'normal cyclic prefix'. So each PHICH after spreading with a 4 bits orthgonal sequence becomes 12 bits. iii) PHICH is modulated in BPSK and this means 'one symbol carries one bit'. And this in turn means we need 12 symbols for each PHICH (each ACK or NACK). iv) Each RE (Resource Elements) carries one symbol. So we need 12 REs to carry one PHICH (one ACK or NACK). v) one REG is made up of 4 REs. So we need 3 REGs to carry one PHICH. vi) These three REGs for one PHICH is distributed evenly across the whole bandwidth. From those multiple Groupes in a system bandwith and multiple PHICHs within each PHICH group, how UE would know exactly which PHICH to look for ? For the very details, you have to understand the procedure described in 9.1.2 PHICH Assignment Procedure of 36.213. As I mentioned above, you have to know the PHICH group number and orthogonal sequence index to locate the specific PHICH. UE figure out these two numbers from the lowest PRB index of the first slot of the PUSCH transmission and DMRS cyclic shift.

LTE Quick Reference CCE Index Calculation

Go Back To Index

Home : www.sharetechnote.com

If you are not familiar with what is CCE, refer to Resource Element Management section first. CCE Index is the CCE number at which the control channel data is allocated. Normally this index changes for each subframe, meaning that the control channel data allocated in each subframe changes subframe by subframe. 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. Step 1 : Figure out all the REs that can be reserved for PDCCH allocation. RE's for PDCCH = Total Available RE's within control symbols - Number of RE's used for reference signals - Number of RE's used in PHICH - Number of RE's used in PCFICH 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

For further details of the procedure, refer to TS 36.213 - 9.1.1 PDCCH Assignment Procedure. 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 / 4) ii) All the possible blocks assuming Aggregation Level = 2 (= 16 / 8) 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.

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).

LTE Quick Reference

Go Back To Index

Home : www.sharetechnote.com

CFI (Control Format Indicator)

CFI is a indicator telling how many OFDM symbols are used for carrying PDCCH at each subframe. If CFI is set to be 1 for a subframe, it means one symbol (the first symbol) at the subframe is used for PDCCH allocation. If CFI is 2, it means two symbols (the first and the second symbol) are used for PDCCH. If CFI is 3, you know the answer -:)

This CFI is carried by a specific physical channel called PCFICH. PCFICH is carrying only CFI without any other information. You may ask "why do we need a special physical channel carrying only one number ?". It is because CFI is made up of 31 bits data even though the types of the bit pattern is only 4. The bit pattern and the CFI value mappingis as follows (3GPP 36.212 5.3.4 Control format indicator).

Reshmi Kalathil

04467412000 9884589997 Reshmi.k@hcl.i