Every downlink assignment has to tell the UE which resource blocks carry its PDSCH. LTE can write that information into a DCI in three different ways, and the choice is a trade between flexibility and the number of bits it costs.

Reference to : TS 36.213 7.1.6 Resource allocation

Resource Allocation Type specifies the way in which the scheduler allocate resource blocks for each transmission. Just in terms of flexibility, the way to give the maximum flexibility of resource block allocation would be to use a string of a bit map (bit stream), each bit of which represent each resource block. This way you would achieve the maximum flexibility, but it would create too much complication of resource allocation process or too much data (too long bit map) to allocate the resources.

So LTE introduces a couple of resource allocation types and each of the resource allocation type uses a predefined procedures. There are three different resource allocation types in LTE, Resource Allocation Type 0, 1, 2.

Let's put a number on the problem first. At 20 MHz the downlink has 100 RBs, so a plain bitmap would cost 100 bits in every assignment. The three types are three different ways of cutting that cost. Type 0 and Type 1 still use a bitmap, but a shorter one. Type 2 drops the bitmap and sends only a start and a length.

• Which DCI format uses which resource allocation type ?
• How does Resource Allocation Type 0 address the resource blocks ?
• How does Resource Allocation Type 1 reach a single RB ?
• How does Resource Allocation Type 2 describe a contiguous run of RBs ?
• Reference

Which DCI format uses which resource allocation type ?

The UE does not have to guess the type. The DCI format it decoded already narrows the choice, and for most formats it settles it completely. The table below gives that mapping for the downlink formats of the first LTE releases.

The resource allocation header is a single bit. 36.213 clause 7.1.6 reads the value 0 as type 0 and the value 1 as type 1. The bit is not always there, though. 36.212 clause 5.3.3.1.2 removes it when the downlink has 10 PRBs or fewer, and the UE then assumes type 0. At 1.4 MHz there are only 6 RBs, so a format 1 assignment in that bandwidth is always type 0.

The formats with a type 2 allocation carry no header at all. They do not need one, because the format itself already fixes the type.

The table stops at format 2A, but the rule does not. The formats added in later releases, 2B, 2C and 2D, follow formats 2 and 2A: type 0 or type 1, chosen by the header bit. Two newer families work differently. For a BL/CE UE, MPDCCH format 6-1A normally uses type 2, and it uses type 0 only when ce-pdsch-maxBandwidth-config is 20MHz and the resource block assignment flag is 0. With shortTTI configured, formats 7-1A to 7-1G use type 0 or type 2 as higher layers configure.

One warning before the next sections. The uplink has its own numbering in 36.213 clause 8.1, and the numbers do not mean the same thing there. Uplink type 0 is a contiguous allocation with a RIV, which is close to downlink type 2. Uplink type 1 gives two separate clusters of RBGs. So "type 0" in a DCI format 0 grant and "type 0" in a DCI format 1 assignment are two different schemes.

• The format fixes the family : formats 1A, 1B, 1C and 1D always use type 2, and formats 1, 2, 2A, 2B, 2C and 2D use type 0 or type 1.
• One header bit separates type 0 from type 1 : 0 means type 0 and 1 means type 1, and both types share the same field length.
• No header at 10 PRBs or fewer : the bit is removed and type 0 is assumed.
• Uplink types are numbered separately : uplink type 0 and type 1 in 36.213 clause 8.1 are different schemes from the downlink types on this page.

How does Resource Allocation Type 0 address the resource blocks ?

Type 0 keeps the bitmap from the introduction and makes it shorter. It does that by letting one bit stand for several neighbouring RBs instead of one. How many RBs share a bit depends on the bandwidth, and that number is the RBG size.

Resource Allocation Type 0 : This is the simplest way of allocation resources. First it divides resource blocks into multiples of groups. This resource block group is RBG(Resource Block Group) called. The number of resource block in each group varies depending on the system band width. It means RBG size gets different depending on the system bandwidth. The relationship between RBS size (the number of resouce block in a RBG) and the system bandwidth as follows.

The table above is written in MHz, but 36.213 Table 7.1.6.1-1 is written in RBs. It gives P = 1 up to 10 RBs, P = 2 from 11 to 26, P = 3 from 27 to 63 and P = 4 from 64 to 110. The six standard bandwidths have 6, 15, 25, 50, 75 and 100 RBs, so each one falls in the row the table above shows.

Resource allocation type 0 allocate the resources using a bitmap and each bit represents one RBG.

The data hierachy in this type is "RB --> RGB" and the resource allocation is done at the level of RBG. Following is an example in RA Type 0 for 10 Mhz BW. One thing you have to notice here is each bit in the bitmap represents one RBG, not one RB.

The example below starts from a decoded DCI format 1 with RAType0 selected. Three bits of the RB-Assign string are set, and the arrows follow each of them down to the RBG it switches on. The two tables at the bottom show where the RBG size of 3 comes from.

Type 0 at 10 MHz. Three set bits give nine RBs, because every bit carries a whole RBG of 3 RBs.

• Bits 2, 3 and 5 are set : they switch on RBG 2, RBG 3 and RBG 5, which are RBs 6 to 11 and RBs 15 to 17.
• The bitmap is read from the MSB : 36.213 maps RBG 0 to the MSB and the last RBG to the LSB, so bit 0 is the leftmost bit of RB-Assign.
• There are 17 RBGs, not 16 : 50 RBs in groups of 3 leave 2 RBs over, so the last group, RBG16, holds only RBs 48 and 49.
• The two tables agree : the 10 MHz row of the page's table and the 27 to 63 row of Table 7.1.6.1-1 both give P = 3.

The bitmap length follows directly from the RBG size. It has one bit per RBG, so it is N_RB^DL / P bits, rounded up. That is 17 bits at 10 MHz and 25 bits at 20 MHz, against the 50 and 100 bits a plain RB bitmap would need.

The saving has a price, and you should keep it in mind when you read a scheduler log. The smallest thing type 0 can allocate is one RBG. At 20 MHz that is 4 RBs, so a UE that needs one RB still receives four. Type 1 exists to fix exactly that.

• One bit per RBG : the bitmap is N_RB^DL / P bits, rounded up, so 17 bits at 10 MHz.
• The last RBG can be short : when P does not divide the RB count, the final group holds the remainder.
• Any set of RBGs is allowed : the RBGs do not have to be contiguous, as bits 2, 3 and 5 in the example show.
• The granularity is coarse at wide bandwidth : at 15 MHz and 20 MHz the smallest possible allocation is 4 RBs.

How does Resource Allocation Type 1 reach a single RB ?

Type 1 has to address single RBs, and it has to do that in the same number of bits as type 0. The header bit is the only thing that tells the two types apart, so the field length cannot change. Type 1 solves this by addressing only part of the bandwidth in each assignment.

Resource Allocation Type 1 : I don't know how to explain about this type without using a well illustrated picture (I will try to create it later). Like in Resource Allocation Type 0, this RA type (Resource Allocation Type) is also using bitmap for the allocation, but in this RA type an additional layer was added. The new layer (hiearchy) is RBG Subset. So the overal hierarchy is "RB --> RBG --> RBG Subset" and the resource allocation is done at 'RBG Subset' level. One RBG Subset is made up of mulple RBGs. Exactly how many RBGs are in one RBG Subset varies depending on the bandwidth, but the number of RBs within a RBG is the same as number RBGs within an RBG Subset. Following is an example in RA Type 1 for 10 Mhz BW. Things you have to notice here are 

• Each bit in the bitmap represents RB.
• The RBGs are spread across multiple subsets as shown below, and each RBG belongs to exactly one subset.
• The number of subsets is equal to the number of RBs within a RBG.
• You can not allocate all RBs since there is no subset which can covers all RBs.

The example below uses the same 10 MHz bandwidth as the type 0 example, so P = 3 and there are three subsets. The decoded DCI selects subset 01 with no shift. The rows under the RB ruler show which RBs belong to each subset and the position each RB has inside its subset.

Type 1 at 10 MHz. The subset field picks one of three rows, and the bitmap then picks single RBs inside that row.

• Subset 01 is subset 1 : it holds RBG 1, RBG 4, RBG 7 and every third RBG after them, which is every P-th RBG starting from RBG 1.
• Bits 2, 3 and 5 select RBs 5, 12 and 14 : positions 0 to 2 of subset 1 are RBs 3 to 5, and positions 3 to 5 are RBs 12 to 14.
• The numbers in each row are positions, not RB indices : they restart from 0 in each subset and count only the RBs of that subset.
• The subsets are not the same size : subset 0 runs to position 17 and subset 1 to position 16, because the short RBG16 falls in subset 1.

Now let's count the bits, because the count explains the shift field. 36.213 clause 7.1.6.2 splits the type 1 field into three parts. The first part selects the subset and takes log₂P bits, rounded up. The second part is the one bit shift. The third part is the bitmap, and it gets whatever remains of the type 0 length.

At 10 MHz the type 0 length is 17 bits. The subset takes 2 of them and the shift takes 1, so the bitmap has 14 bits. But subset 0 holds 18 RBs and subset 1 holds 17. The bitmap therefore cannot cover a whole subset at once.

The shift bit decides which part of the subset the 14 bits cover. With shift 0 the bitmap starts at the lowest RB of the subset. With shift 1 the window moves up, so the LSB of the bitmap lands on the highest RB of the subset. The example above has shift 0, so its 14 bits cover positions 0 to 13 of subset 1. Positions 14, 15 and 16 are RBs 41, 48 and 49, and they are out of reach in this assignment.

• Three fields in the type 0 length : subset selection, a one bit shift, and a bitmap that takes the rest.
• The bitmap is shorter than a subset : at 10 MHz it has 14 bits, against 18 RBs in subset 0.
• The shift picks the window : 0 aligns the bitmap with the bottom of the subset, 1 aligns it with the top.
• Single RB resolution has a cost : one assignment only reaches RBs of one subset, so type 1 suits small allocations spread across the band.

How does Resource Allocation Type 2 describe a contiguous run of RBs ?

Type 2 gives up the bitmap altogether. A run of contiguous RBs is fully described by where it starts and how long it is. Those two numbers fit in far fewer bits than any bitmap, which is why the compact formats 1A and 1C use this type.

Resource Allocation Type 2 : In this case, network allocate a set of contiguous RBs. But this contiguous RB is "Virtual" concept, not the "Physical" concept. It means that even though MAC layer allocate the multiple contiguous RBs, they may not be aligned contiguously when it get transmitted at PHY layer. This means that there should be a rule/algorithm to convert this logical(virtual) RB allocation to physical RB allocation.

There are two type of the conversion, one is 'localized' and the other is 'distributed'. When you select 'localized', both virtuall allocation and physical allocation allocate RBs in contiguous way. When you select 'distributed', the virtual RB allocation is contiguous, but physical allocation is not contiguous (they are distributed over wider frequency ranges). Following is an example in RA Type 2 for 10 Mhz BW.

The example below starts from a decoded DCI format 1A with LocalizedVRB selected and a RIV of 259. The two lines in the middle turn that single number into a length and a start. The ruler at the bottom marks the six RBs that result.

Type 2 at 10 MHz. One RIV of 259 carries both numbers: a length of 6 RBs and a start at RB 9.

• Floor of 259 over 50, plus 1, gives 6 : that is the number of RBs, L_CRBs.
• 259 mod 50 gives 9 : that is the starting RB, RB_start.
• 50 is N_RB^DL : the drawing calls it the max number of RBs for the specified system bandwidth.
• LocalizedVRB means VRB equals PRB : the six RBs 9 to 14 are therefore also the physical RBs, and they span parts of RBG 3 and RBG 4.

The decoding in the example is only half of the rule, and this is the part people often miss. 36.213 clause 7.1.6.3 builds the RIV in one of two ways, depending on the length.

• If L_CRBs - 1 is at most floor(N_RB^DL / 2), then RIV = N_RB^DL (L_CRBs - 1) + RB_start.
• Otherwise, RIV = N_RB^DL (N_RB^DL - L_CRBs + 1) + (N_RB^DL - 1 - RB_start).

The example has L_CRBs = 6 at 50 RBs, so it uses the first line: 50 x 5 + 9 = 259. The division in the drawing simply undoes that line. For a long allocation the same division gives the wrong answer. Take 40 RBs starting at RB 5. The second line applies, and it gives 50 x 11 + 44 = 594. Floor of 594 over 50, plus 1, is 12, and 594 mod 50 is 44, and neither of those is the real allocation.

So a decoder needs one more check. Let a be floor(RIV / N_RB^DL) + 1 and b be RIV mod N_RB^DL. If a + b is at most N_RB^DL, the first line was used, and the length is a and the start is b. Otherwise the second line was used, and the length is N_RB^DL - a + 2 and the start is N_RB^DL - 1 - b. For RIV 594 that gives a length of 40 and a start of 5, which is the allocation we began with.

The choice between localized and distributed is signalled, not configured. In formats 1A, 1B and 1D a one bit flag selects it, with 0 for localized and 1 for distributed. Format 1C always uses distributed VRBs. For distributed VRBs, 36.211 clause 6.2.3.2 interleaves the VRB numbers and places the second slot a gap away from the first. At 10 MHz that gap is N_gap,1 = 27 or N_gap,2 = 9, and the DCI says which one applies.

• Two numbers in one field : the RIV carries both the start and the length of a contiguous VRB run.
• The RIV has two branches : the simple divide and modulo decoding only works when the length is at most half the bandwidth plus one.
• Localized keeps the run contiguous : the VRBs map straight onto the same PRBs.
• Distributed spreads it : the VRBs are interleaved, and the second slot is placed N_gap away, which adds frequency diversity.
• Format 1C has no choice : it always uses distributed VRBs, while 1A, 1B and 1D carry a one bit flag.

Reference

The sections above rely on three specifications. 36.213 defines the three types, 36.212 defines the DCI fields that carry them, and 36.211 defines the distributed VRB mapping.

• [1] 36.213 : 3GPP - E-UTRA; Physical layer procedures, v19.4.0. Clause 7.1.6 covers the downlink resource allocation types, and clause 8.1 the uplink ones.
• [2] 36.212 : 3GPP - E-UTRA; Multiplexing and channel coding, v19.3.0. Clause 5.3.3.1.2 defines the resource allocation header of DCI format 1.
• [3] 36.211 : 3GPP - E-UTRA; Physical channels and modulation, v19.3.0. Clause 6.2.3.2 defines distributed VRBs and Table 6.2.3.2-1 the gap values.