>
HomeLTE 4GPHY — Physical LayerThroughput Calculation
📶 PHY — Physical LayerAdvanced

LTE Throughput Calculation

Peak vs actual throughput — RE counting, TBS tables and UE categories, with worked examples.

📚 3GPP-basedTS 36.213TS 36.306

LTE throughput has two honest numbers, and confusing them is the classic interview trap. The peak is a look-up: find the Transport Block Size for your resource-block count and modulation in the TS 36.213 tables, deliver it once per 1 ms subframe, and scale by how many spatial streams and how many carriers you run. The practical figure is always smaller, because reference signals, the control region and the broadcast channels each claim resource elements before your data gets a seat — and because link adaptation, retransmissions and scheduling almost never let a cell run flat-out. This page counts the resource elements to build the intuition, then turns that count into Mbps the way the standard actually does: through the TBS table, not a closed-form equation.

Introduction

Throughput is the bottom-line answer to “how fast is this link?” — the number of user-data bits per second delivered on the shared data channels, PDSCH in the downlink and PUSCH in the uplink, after every physical-layer overhead has been stripped away. It is the metric operators sell, the metric UE categories are written in, and the metric every capacity plan traces back to.

It matters at two very different moments. When you size a network or check whether a device meets its UE category, you reach for the peak — the theoretical ceiling from the TBS tables. When you troubleshoot why a user “only” gets 100 Mbps on a “150 Mbps” cell, you reach for the practical figure and the chain of overheads and scheduling realities that separate the two. Conflating them is the single most common throughput mistake.

The mechanics are more of a look-up than a calculation. LTE fixed its Transport Block Sizes in TS 36.213 tables, so the peak is a table entry times a fixed frame rate times a layer count — not a first-principles bits-per-symbol product. This page builds the intuition by counting resource elements, then shows how the standard turns that intuition into a headline number.

Why throughput accounting matters

💡

In plain words: think of the radio grid as a commuter train. The timetable capacity (every seat, every carriage, every departure) is the peak; but some seats are reserved for staff and signage before any passenger boards (reference signals and control), and in real life the train rarely runs full and some passengers have to ride twice because they missed their stop (retransmissions). The number of passengers who actually reach their destination per hour is the practical throughput — always less than the timetable promises.

Concretely, you need this accounting for three jobs. To plan capacity, you must know the realistic bits-per-second a cell delivers under load, not the marketing ceiling. To check category compliance, you must be able to derive a device’s declared peak from N_PRB, I_TBS, layers and carriers and confirm it matches TS 36.306. And to troubleshoot, you must be able to explain the gap between the peak a cell could offer and the rate a user actually sees.

The subtlety that makes this a page rather than a one-liner is that LTE does not let you compute the peak from resource elements and code rate directly — the TBS tables already bake in a nominal overhead. So the RE count is intuition, the table is truth, and knowing which is which is exactly what keeps you from quoting a number that is off by 20%.

What

Throughput is user-data bits delivered per second on the PDSCH (downlink) or PUSCH (uplink), after every physical-layer overhead has been removed.

Why

UE category definitions in TS 36.306 are expressed as peak rates; capacity planning, MCS selection and category compliance all trace straight back to this number.

How

Count usable resource elements per RB-pair for intuition, but read the actual peak from the TBS table for the scheduled N_PRB and I_TBS, then multiply by 1000 subframes/s and the layer count.

Counting resource elements

The atomic unit of an LTE grant is the resource-block pair: one RB is 12 subcarriers wide, and over a 1 ms subframe you get 14 OFDM symbols (two slots of 7 symbols each, normal cyclic prefix). So the raw budget per RB-pair per subframe is a fixed rectangle:

REraw = 12 subcarriers × 14 symbols = 168 resource elements  per RB-pair per 1 ms

Those 168 REs are gross, not net. Before a single user bit is mapped, the physical layer spends REs on signals every UE needs to demodulate and every cell needs to broadcast. The net budget that is actually available to PDSCH is what remains after four deductions:

REusable = 168 CRS PDCCH control region (subframe 0/5) PSS/SSS/PBCH DM-RS

Extended cyclic prefix reduces you to 6 symbols per slot (144 REs), but the common assumption — and the one the TBS tables are dimensioned around — is normal CP, so we stay with 168 throughout. Each deduction below has a well-defined cost, and once you have subtracted them you know the fraction of the grid that carries payload. That fraction, roughly 75–85% in a typical macro configuration, is the single most useful sanity check on any LTE throughput claim.

🎯

Key idea: you never actually multiply usable REs by bits-per-RE to get the published LTE peak. The RE count explains why overhead exists and roughly how big it is; the peak itself is a table look-up whose entries already bake in a nominal overhead. Both views matter — one for intuition, one for the exam answer.

Where the REs go

Four consumers reduce the 168 REs before PDSCH data is mapped. Their costs differ by transmission mode, antenna count and which subframe you are in, so the honest overhead is a range, not a single number.

OverheadWhat it isTypical cost / RB-pair
CRSCell-specific reference signals — the pilots for channel estimation, present in every RB of every subframe4 RE / port for 1 port; 8 RE for 2 ports; 16 RE for 4 ports
PDCCH regionControl region: the first 1–3 OFDM symbols carry PCFICH, PHICH and PDCCH across the whole band12–36 RE (1–3 symbols × 12 subcarriers)
PSS/SSS/PBCHPrimary/secondary sync signals and the broadcast channelCentre 6 RBs only, subframes 0 & 5 — negligible averaged across a wide band
DM-RSUE-specific demodulation RS, only in the beamformed transmission modes (TM7–10)12 RE per RB-pair when used (replaces reliance on CRS)

For the classic CRS-based 2×2 case (transmission mode 3 or 4) in an ordinary subframe, take a 2-symbol PDCCH region and 2 CRS ports: 168 − 24 (control) − 16 (CRS) = 128 usable REs per RB-pair, roughly 76% efficiency before code rate is even considered. In subframes 0 and 5 the centre six RBs lose a further slice to PSS, SSS and (in subframe 0) PBCH, but because those signals sit only in the middle 1.08 MHz, their weight vanishes once you average over 100 RBs. That is precisely why the TBS tables can quote one number per bandwidth: the sync/broadcast cost is a rounding error at 20 MHz.

One RB-pair per subframe = 168 resource elements PDCCH CRS RS/sync PDSCH usable data 24 RE 16 RE ~0 avg 128 RE 2-symbol control region + 2-port CRS → 128 of 168 RE carry user data (≈76%); PSS/SSS/PBCH bite only the centre 6 RBs of subframes 0 & 5, negligible across 100 RBs.
Figure 1. Resource-element overhead breakdown for a 2×2 CRS-based downlink RB-pair.

Peak throughput via the TBS table

Here is the part students most often get wrong: for LTE you do not derive the peak by hand from REs and code rate. You look it up. The scheduler picks a modulation-and-coding scheme, which maps (via TS 36.213 §7.1.7) to a TBS index I_TBS. The row for that I_TBS and the column for the number of allocated resource blocks N_PRB give the Transport Block Size — the exact number of data bits delivered in one transport block in one 1 ms TTI. That number already accounts for a nominal overhead, which is why it is smaller than a naive REs×bits calculation would suggest.

Peak (bps) = TBS(NPRB, ITBS) × 1000 subframes/s × Nlayers

The × 1000 comes from the fixed LTE frame structure: every subframe is 1 ms, so there are exactly 1000 TTIs per second regardless of bandwidth or MCS. N_layers is the number of spatial streams — equivalently the number of transport blocks (codewords) carried in parallel. Single-stream is one codeword; 2×2 spatial multiplexing carries two codewords; 4×4 carries up to four layers mapped across two codewords. Carrier aggregation adds the per-carrier peaks together, one TBS×1000×layers term per component carrier:

PeakCA = Σ cc  TBScc × 1000 × Nlayers,cc

Every headline LTE number in existence is one of these three formulas with different inputs. A 10 Mbps IoT device, a 150 Mbps Category 4 phone, and a gigabit Category 16 modem all fall out of exactly the same arithmetic — only N_PRB, I_TBS, N_layers and the carrier count change.

🔀

LTE ↔ NR: NR abandons the fixed TBS table. Instead it computes an intermediate information size N_info = N_RE × R × Q_m × ν × layers (from the actual scheduled resource elements, target code rate, modulation order and layer count) and then quantises it to a byte- and LDPC-friendly TBS per TS 38.214. So the LTE “look it up” step becomes an NR “calculate it” step — and the fixed ×1000 subframe rate becomes a numerology-dependent slot rate (14 symbols per slot, but 1/2/4/8/16 slots per ms as the subcarrier spacing grows).

Worked example: 20 MHz, 64QAM, 2×2

Take the canonical Category 4 configuration: 20 MHz bandwidth (which is N_PRB = 100 resource blocks), highest 64QAM MCS so I_TBS = 26, and 2×2 spatial multiplexing (two codewords). From the TS 36.213 TBS table, the entry at I_TBS = 26, N_PRB = 100 is 75376 bits.

Single stream: 75376 × 1000 = 75.376 Mbps

2×2 (two codewords): 75376 × 1000 × 2 = 150.752 Mbps

That 150 Mbps is the number on every LTE marketing slide of the early 2010s, and it is exactly the Category 4 downlink ceiling. Halve the streams and you land on the ~75 Mbps single-antenna figure; the second stream is carrying the other half. From here the multipliers are simple: 4×4 MIMO doubles the layers again toward ~300 Mbps, 256QAM (Release 12) lifts I_TBS to give roughly a third more bits per RE, and carrier aggregation of N carriers multiplies the whole result by up to N. A three-carrier, 4×4, 256QAM device is how LTE-Advanced Pro reaches the gigabit headline. The table below walks the peak up from a single antenna to Category 16, each row just changing one input to the formula.

ConfigurationMIMOModulationPer-CC bits/TTIApprox. DL peak
20 MHz (100 RB)1×164QAM75376~75 Mbps
20 MHz (100 RB)2×264QAM75376 × 2~150 Mbps
20 MHz (100 RB)4×464QAM75376 × 4~300 Mbps
20 MHz (100 RB)2×2256QAM~97896 × 2~200 Mbps
2×20 MHz CA2×264QAM2 × (75376 × 2)~300 Mbps
3×20 MHz CA4×4256QAM3 × (~97896 × 4)~1 Gbps

Notice that the last row — three 20 MHz carriers, four layers each, 256QAM — is 3 × 4 × ~98 kbit × 1000, which lands just under 1.2 Gbps before the category cap trims it to the Category 16 figure of ~979 Mbps. That trimming is the whole point of the next section: the cell can offer more than the UE is allowed to take.

UE categories and the ceilings they impose

A UE cannot exceed the peak its category declares in TS 36.306, no matter how much spectrum the cell offers. The category fixes a soft-buffer size and a maximum number of DL-SCH bits per TTI — that maximum TBS is what truly caps throughput, and it is the number to memorise. Everything else (layers, aggregated carriers) is just how a UE reaches that ceiling. The principal downlink categories:

CategoryDL peakUL peakMax DL TBS / TTIMax DL layersTypical CA
Cat 1~10.3 Mbps~5.2 Mbps1029611 CC
Cat 3~102 Mbps~51 Mbps10204821 CC
Cat 4~150.8 Mbps~51 Mbps15075221 CC
Cat 6~301.5 Mbps~51 Mbps3015042 or 42 CC
Cat 9~452 Mbps~51 Mbps4522562 or 43 CC
Cat 11~603 Mbps~51 Mbps6030082 or 44 CC (256QAM)
Cat 12~603 Mbps~102 Mbps6030082 or 44 CC
Cat 16~979 Mbps~105 Mbps979376up to 4up to 32 CC, 256QAM

Read the table as multipliers of the 75376-bit brick. Category 3 and 4 both cap around two bricks per TTI (Cat 4 gets the full 150752, Cat 3 is fractionally lower). Category 6 is four bricks — reachable either as 4×4 on one carrier or 2×2 on two aggregated carriers, which is why its layer/CA cell reads “2 or 4”. By Category 16 the ceiling is roughly thirteen bricks, assembled from many carriers, four layers and 256QAM at once. The category never says how you reach the number, only that you may not exceed it: the honest peak for a deployment is the minimum of what the cell configuration allows and what the UE category permits.

📘

Spec note: from Release 12 onward, downlink and uplink categories were decoupled (ue-CategoryDL and ue-CategoryUL signalled separately), so a device can advertise, say, DL Category 12 with a much lower UL category. The single-number “Cat 4” shorthand is really the legacy coupled category from TS 36.306 Table 4.1-1.

Downlink vs uplink asymmetry

The category table shows uplink stuck near ~51 Mbps for a long run of categories while downlink races past it. That asymmetry is deliberate and has three roots. First, early UEs shipped a single transmit antenna, so there was no uplink spatial multiplexing — N_layers on PUSCH was 1 while downlink already ran two. Second, the uplink long favoured 16QAM as its top modulation to keep the power amplifier efficient and the peak-to-average ratio manageable; 64QAM uplink and later 256QAM uplink arrived only in later releases and only for good-radio users. Third, the SC-FDMA waveform used on PUSCH (chosen for its lower PAPR, kinder to battery-powered amplifiers) constrains allocation flexibility compared with the downlink’s OFDMA.

DirectionWaveformReference signalTop modulation (early → later)Spatial streams
Downlink (PDSCH)OFDMACRS / DM-RS64QAM → 256QAMup to 4 (later 8)
Uplink (PUSCH)SC-FDMADM-RS / SRS16QAM → 64QAM → 256QAM1 (later up to 4)

The uplink TBS look-up works identically — same TS 36.213 machinery, same × 1000 — but the inputs are smaller, so the numbers are smaller. As uplink MIMO and 64/256QAM uplink became mainstream (Category 12 and up), the uplink ceiling finally climbed past 100 Mbps. For most real deployments, though, the uplink budget is still the scarce one, and it is what limits video calls and cloud backups long before the downlink runs out.

Practical throughput: why the field number is lower

Peak assumes an impossible best case: every RB scheduled to one user, every subframe, at the top MCS, with zero retransmissions. Real cells never do this, and the gap between the peak and what a user actually measures is worth naming explicitly.

Reason practical < peakEffect on throughput
Link adaptation to a lower MCSScheduler backs off from I_TBS = 26 to hold ~10% BLER; fewer bits/RE away from cell centre
HARQ retransmissionsEach retransmission spends airtime re-sending bits already counted once, cutting net rate
Partial RB allocationCell rarely grants all 100 RBs to one UE every subframe; shared among many users
TDD subframe splitTDD gives only a fraction of subframes to each direction (e.g. config 2 ≈ 60% DL)
Control & RS overhead variation3-symbol PDCCH region or 4-port CRS shrinks the usable RE fraction further

A useful field rule of thumb: a healthy 20 MHz 2×2 FDD cell delivers 100–120 Mbps to a good-radio user, not the 150 Mbps peak — roughly 70–80% of ceiling in strong signal, tailing off toward the edge. TDD trades away more, because the direction you care about only owns some of the subframes. When someone quotes a throughput number, the first question is always: peak or practical, and under which assumptions.

From peak to practical — 20 MHz 2×2 64QAM downlink Peak (TBS × 1000 × 2 layers) = 150.8 Mbps − link adaptation / MCS back-off − HARQ retx & partial allocation ≈ 100–120 Mbps Longer bar = more throughput; each deduction narrows the delivered rate.
Figure 2. The peak-to-practical waterfall: nominal ceiling shaved by adaptation, retransmission and sharing.

⚠ Common pitfalls / gotchas

  • Quoting peak as if it were deliverable. The 150 Mbps ceiling assumes one user owns every RB, every subframe, at the top MCS, with zero retransmissions — conditions that never coexist in a loaded cell.
  • Deriving the peak from REs × bits × code rate. LTE’s peak is a TBS-table look-up; the naive product over-counts because the table already embeds a nominal overhead.
  • Ignoring the UE category cap. A cell that supports 4×4, 256QAM and CA cannot lift a Category 4 phone past 150752 bits/TTI. Peak is the minimum of cell capability and UE category.
  • Forgetting the ×1000 is fixed only in LTE. It comes from the 1 ms subframe; carrying the same ×1000 into an NR calculation is wrong, since NR’s slot rate scales with numerology.
  • Assuming symmetric DL/UL. Uplink peaks sat near ~51 Mbps for many categories due to single-Tx, 16QAM ceiling and SC-FDMA; do not mirror the downlink number onto the uplink.

Summary

LTE throughput lives on two numbers. The peak is a look-up, not a derivation: read the Transport Block Size from the TS 36.213 table for your I_TBS and N_PRB, multiply by the fixed 1000 subframes/s, then by the layer count, and sum over aggregated carriers. That single formula, with different inputs, produces every headline figure from a 10 Mbps IoT device to a gigabit Category 16 modem. The RE count (168 per RB-pair, minus CRS, control, sync/broadcast and DM-RS) is there to build intuition about where roughly 15–25% of the grid goes, not to compute the peak — the table already bakes that overhead in.

The practical number is always lower, and for nameable reasons: link adaptation backs the MCS off to hold ~10% BLER, HARQ resends bits, the cell shares RBs among users, TDD splits the subframes, and control/RS overhead varies. Two ceilings bound everything — what the cell configuration allows and what the UE category in TS 36.306 permits — and the honest deployment peak is the minimum of the two. When a throughput number is quoted, always ask: peak or practical, and under which assumptions.

Quick Q&A

Q&A Interview quickfire

Q. Why is LTE peak a table look-up and not a formula like NR?

A. LTE fixed its Transport Block Sizes in the TS 36.213 tables, indexed by N_PRB and I_TBS. Those entries already embed a nominal overhead, so you read the bits-per-TTI directly and multiply by 1000 and the layer count. NR replaced this with the computed N_info/quantisation procedure of TS 38.214.

Q. Where does the 150 Mbps for Category 4 come from?

A. 20 MHz is 100 RBs; the top 64QAM row (I_TBS = 26) at 100 RBs is TBS = 75376 bits per TTI. Times 1000 TTIs/s is 75.4 Mbps per stream; 2×2 spatial multiplexing carries two codewords, so 2 × 75.376 ≈ 150.75 Mbps.

Q. If a cell supports 4×4 256QAM CA, why might a phone still cap at 150 Mbps?

A. The UE category. A Category 4 device is limited to a max DL TBS of 150752 bits/TTI and 2×2, regardless of cell capability. Peak is the minimum of cell configuration and UE category, so you must check both.

Q. Why does the usable RE count barely change between narrow and wide bandwidth?

A. Because PSS/SSS/PBCH sit only in the centre 6 RBs of subframes 0 and 5. Their cost is fixed while the band grows, so per-RB they vanish. CRS and the PDCCH region, by contrast, scale with the band and dominate the overhead.

Q. Why is LTE uplink peak so much lower than downlink for early categories?

A. Single transmit antenna (no uplink spatial multiplexing), 16QAM as the top uplink modulation, and the SC-FDMA waveform’s allocation constraints. Uplink only passed ~100 Mbps once uplink MIMO and 64/256QAM arrived around Category 12.

Q. What is a realistic practical rate for a 20 MHz 2×2 cell?

A. Around 100–120 Mbps to a good-radio FDD user — roughly 70–80% of the 150 Mbps peak — after MCS back-off, HARQ retransmissions and sharing the RBs with other UEs. TDD delivers less per direction because subframes are split.

Where this connects

The I_TBS that drives every look-up here is set by the MCS the scheduler picks, the extra streams and carriers come from MIMO and aggregation, and the bits themselves ride the shared data channel.