Resource Allocation (Type 0/1/2 & RIV) in LTE 4G

Introduction

Frequency-domain resource allocation is the part of an LTE scheduling grant that names which resource blocks a UE should receive on (PDSCH) or transmit on (PUSCH). It is one field inside the DCI the eNB sends on the PDCCH, and its interpretation is defined in TS 36.213 (procedures) and TS 36.212 (DCI coding).

This field is read on every single grant. Each time the scheduler picks a UE for a subframe, the UE must decode this field to know exactly which PRBs are its own — anything it misreads it either fails to receive or transmits in the wrong place. Because the PDCCH is blind-decoded dozens of times per subframe, the field also has to be small, which is the tension the whole design resolves.

It matters because the choice of allocation type is where the scheduler expresses its strategy: pack a UE onto the specific PRBs where its channel is best, or spread it across the band so no single fade can kill the transport block, all while spending as few DCI bits as possible. Understanding the three types tells you both what the eNB is trying to do and how the UE recovers its PRBs from a handful of bits.

Why three allocation types exist

Concretely, a plain per-PRB bitmap would cost 100 bits at 20 MHz — far too much for a control channel that must be blind-decoded dozens of times per subframe. So 3GPP defines three resource allocation types that trade granularity against signalling bits. The deeper reason non-contiguous types exist at all is frequency-selective scheduling and diversity: a fading channel is good in some parts of the band and poor in others, so the scheduler wants either to place a UE on the scattered good PRBs (Type 0/1) or, when it does not know the channel, to spread the UE across the whole band so no single fade kills the transport block (Type 2 distributed).

The Job: Point the UE at its PRBs

An LTE carrier is a grid of Physical Resource Blocks (PRB) across frequency — 6 PRBs at 1.4 MHz up to 100 PRBs at 20 MHz. A downlink assignment must tell the UE exactly which of those PRBs carry its PDSCH, and an uplink grant must tell it which carry its PUSCH. The obvious idea — a plain bitmap with one bit per PRB — costs 100 bits at 20 MHz, far too much for a control channel that must be blind-decoded dozens of times per subframe. So 3GPP defines three resource allocation types that trade granularity against signalling bits, and the DCI format the eNB transmits decides which type is in play.

There is a fourth idea worth naming up front, because it explains why non-contiguous types even exist: frequency-selective scheduling and diversity. A fading channel is good in some parts of the band and poor in others. If the scheduler knows the channel (from a CQI report), it wants to place a UE on the good PRBs, which may be scattered — that is Type 0/1. If it does not know the channel, it wants to spread the UE across the whole band so no single fade can kill the whole transport block — that is Type 2 distributed. The rest of this page works through each mechanism in detail.

Type 0 — Resource Block Group Bitmap

Type 0 chops the whole band into Resource Block Groups (RBG), each a fixed run of P consecutive PRBs, and hands the UE a bitmap with one bit per RBG. A 1 means “this RBG is yours.” The group size P grows with the bandwidth so the bitmap never gets too long — the same trick a filesystem uses when it grows cluster size on a bigger disk to keep the allocation table small.

This is TS 36.213 Table 7.1.6.1-1. The number of groups is N_RBG = ⌈N_DL_RB / P⌉. At 20 MHz, P = 4, so 100 PRBs become 25 RBGs and the bitmap is only 25 bits instead of 100. At 10 MHz, P = 3 gives 50 PRBs → ⌈50/3⌉ = 17 RBGs. The MSB of the bitmap addresses the lowest-frequency RBG (RBG 0); the LSB addresses the highest.

The cost of the compression is granularity: you can only be assigned in chunks of P PRBs, and if N_DL_RB is not a multiple of P the last RBG is smaller than P. At 10 MHz, 50 is not a multiple of 3, so the final RBG (RBG 16) holds only 50 − 16×3 = 2 PRBs rather than 3. The UE handles this edge case from the same table; it never guesses.

Type 1 — Bitmap Within an RBG Subset

Type 1 is the fine-grained cousin of Type 0. Instead of selecting whole RBGs, it works inside one RBG subset and lets the UE pick individual PRBs. The RBGs of the band are partitioned into P subsets, where subset p (for p = 0…P−1) contains every P-th RBG starting from RBG p. So with P = 4 there are 4 subsets, and subset 0 holds RBGs 0, 4, 8, 12…, subset 1 holds RBGs 1, 5, 9…, and so on.

The Type 1 field is the same total width as the Type 0 bitmap — that is deliberate, so both interpretations fit one shared DCI field and a single header bit chooses between them. Type 1 spends that width on three things:

The result is still non-contiguous, but now at single-PRB resolution rather than P-PRB resolution. The trade-off is reach: because only one subset is addressable per DCI, a single Type 1 assignment cannot touch PRBs spread across all subsets at once — it sees only every P-th RBG. The shift flag exists precisely to soften that limit: when the bitmap is shorter than the subset it addresses, the shift bit chooses whether the bitmap covers the low end or the high end of the subset's PRBs.

In practice Type 1 is used when the scheduler needs precise, single-PRB placement for a small allocation — for instance to fit a UE into a gap left between larger allocations — and does not need to reach across the whole band in one grant. Type 0 remains the workhorse for larger, coarser downlink allocations.

Type 2 — Localized / Distributed VRBs and the RIV

Type 2 assumes the allocation is one contiguous run of Virtual Resource Blocks (VRB) — a start block RB_start and a length L_CRBs. Rather than send those two numbers separately (which would waste codepoints on impossible combinations, like a run that starts near the top of the band yet claims to be very long), TS 36.213 packs them into a single Resource Indication Value (RIV).

Crucially, Type 2 works on VRBs, not directly on PRBs, and a 1-bit localized/distributed flag in the DCI decides how those VRBs map to physical resource:

• Localized VRB (LVRB): VRB n maps straight to PRB n. The contiguous run in VRB space is a contiguous run in the actual spectrum. This is the simple, low-overhead case.
• Distributed VRB (DVRB): the contiguous VRB run is spread across the band by a two-step interleaver plus a frequency hop at the slot boundary, governed by a distributed gap N_gap. The transport block therefore samples many parts of the band, buying frequency diversity even though the DCI still only encodes a start and a length. For larger bandwidths (N_DL_RB ≥ 50) two gap values (N_gap,1 and N_gap,2) are defined; a bit selects which.

The clever part is that this single formula packs every valid (start, length) pair into a unique RIV without wasting codepoints — the two branches fold the “large length” half of the space back on itself, so RIV fits in exactly ⌈log₂(N_DL_RB × (N_DL_RB+1)/2)⌉ bits. That is 13 bits at 20 MHz, versus the 25 a Type 0 bitmap needs and the 100 a raw per-PRB bitmap would need.

Encode example, 20 MHz (N_DL_RB = 100). Say RB_start = 10 and L_CRBs = 5. Here L_CRBs−1 = 4 ≤ ⌊100/2⌋ = 50, so the first branch applies: RIV = 100 × 4 + 10 = 410.

Decode. To reverse a RIV, compute a trial length L′ = ⌊RIV / N_DL_RB⌋ + 1 and a trial start S′ = RIV mod N_DL_RB. If L′ + S′ ≤ N_DL_RB the first branch was used, so L_CRBs = L′ and RB_start = S′. Otherwise the second branch was used: L_CRBs = N_DL_RB − L′ + 2 and RB_start = N_DL_RB − 1 − S′.

So RIV = 410 decodes to “start at PRB 10, 5 PRBs long,” RIV = 27 decodes to a minimal single-PRB run at PRB 27, and RIV = 3189 decodes to “start at PRB 10, 70 PRBs long” — the second branch handling the long allocation the first branch has no room for. The whole 20 MHz allocation is described by one small number.

Two Types, One Band

Below is a 50-PRB (10 MHz) band shown two ways: Type 0 selecting scattered RBGs by bitmap (P = 3), and Type 2 localized selecting one contiguous run by RIV. The same band, two very different allocation philosophies.

Which DCI Format Uses Which Type

The allocation type is not free-standing — it is fixed by the DCI format the eNB chose. The heavier, MIMO-capable downlink formats carry Type 0/1; the compact and common-search-space formats use Type 2; and the uplink grant is always Type 2 contiguous. The UE knows the format from the search space and payload size, so it always knows which decode rule to apply.

How the Scheduler Chooses

Given three downlink types plus the localized/distributed choice, how does the eNB decide? It is a three-way trade among overhead, granularity, and diversity, driven by what the scheduler knows about the channel and how big the allocation is.

A useful way to hold it all in your head: bitmap types (0/1) buy you shape — the freedom to pick an arbitrary set of PRBs — at the price of more DCI bits. The RIV (Type 2) buys you cheapness — a contiguous run in a handful of bits — and recovers diversity through the distributed-VRB mapping when needed. The eNB reaches for whichever matches the traffic and its knowledge of the channel at that instant.

Summary

LTE frequency-domain allocation is one DCI field that names a UE's PRBs while spending as few bits as possible. Type 0 hands out whole Resource Block Groups by bitmap (coarse, any subset, P-PRB granularity that grows with bandwidth). Type 1 spends the same bit budget on single-PRB resolution inside one RBG subset, softened by a shift flag. Type 2 assumes a single contiguous run and folds its start and length into one RIV, with a 1-bit flag choosing localized mapping or a distributed, interleaved spread for frequency diversity.

The DCI format fixes which type is in force, so the UE always knows the decode rule from where and how it found the grant. Bitmap types buy shape at the cost of bits; the RIV buys cheapness and recovers diversity through distributed VRBs. And because LTE uplink is SC-FDMA, DCI 0 is always a single contiguous Type 2 run — the one hard constraint that never bends in the baseline design.

Quick Q&A