5G NR Throughput Calculation (Method A & B)

Introduction

Throughput calculation is the arithmetic that turns a radio configuration into a bit rate. It is used constantly across the lifecycle: a UE advertises its peak capability at attach; a vendor prints a datasheet number; a planner sizes a transport link; a test engineer compares a live KPI against expectation; and a scheduler, slot by slot, converts a chosen MCS and allocation into the transport block it will actually send. Every one of these is the same physical question — information bits per second on a carrier — answered at a different level of realism.

The two methods this page develops answer that question at the two extremes. Method A (TS 38.306) is the capability ceiling: a single closed-form sum over carriers with a flat overhead fraction and the maximum code rate, giving the number you can never exceed. Method B (TS 38.214) is the realised figure: it counts the resource elements that survive reference signals and configured overhead, applies the code rate and modulation the scheduler actually chose, quantises to a real TBS, and discounts the block-error fraction.

Keeping the two apart matters because they are used for different jobs and they disagree by design. Method A sizes categories and links; Method B predicts sessions and KPIs. Confusing them is the single most common source of "why is my throughput only half the spec sheet?" arguments — the answer is almost always that the spec sheet is Method A and the field is Method B.

Why two throughput numbers exist

The reason there are two numbers is that "usable capacity" has two legitimate boundaries. One draws the line at what the hardware and configuration could theoretically sustain — full band, top modulation, all layers, maximum code rate, a flat allowance for overhead, and no errors. That is a capability figure, and it is what you want when sizing a UE category, a backhaul link, or a marketing claim, because it must not depend on the momentary state of one cell.

The other draws the line at what a scheduler actually delivered: the exact resource elements left after reference signals and control, the code rate and modulation link adaptation really picked for the measured channel, and the fraction of blocks lost to errors and recovered by HARQ. That is a realised figure, and it is what you want when predicting a user session or explaining a drive-test KPI. Both are correct; they simply answer different questions, and every real-world effect can only push the realised number below the ceiling, never above it.

Two ways to count, and why they differ

Both methods answer the same physical question — how many information bits per second can a carrier carry — but they draw the boundary of "usable" in different places. Method A is a capability figure: it asks what a UE's configured band, layers, and modulation could theoretically sustain if the channel were perfect and the scheduler perfectly greedy. Method B is a realised figure: it counts the exact resource elements left after reference signals and control, applies the code rate and modulation the link-adaptation loop actually chose, and discounts the bits lost to block errors.

The gap between the two is not error — it is structure. Peak is a ceiling; Method B is the room you actually live in. Reading the rest of this page is largely about learning why every practical effect can only push the realised number below the ceiling, never above it.

Method A — the peak data-rate formula

The 3GPP approximate maximum data rate (TS 38.306 §4.1.2) sums a per-carrier bit rate over all aggregated carriers. Each carrier contributes layers × bits-per-symbol × code rate × resource-elements-per-second, discounted by a flat overhead.

Every symbol matters, so define them one by one:

Read the core of the expression as a chain of unit conversions. The term N_PRB · 12 is the number of resource elements (subcarriers) in one OFDM symbol — a per-symbol count. Dividing by T_s turns that count into REs per second. Multiplying by the bits carried per RE (Q_m · R_max) turns REs into bits; multiplying by v_Layers spreads it across spatial streams; the scaling factor f lets a UE declare it cannot fully use a band; and the (1 − OH) factor lops off the fraction of REs the standard assumes go to reference and control signals. The leading 10−6 converts bits per second into Mbps.

Overhead, code rate and numerology constants

Three inputs to Method A are effectively constants you look up rather than compute. The flat overhead OH depends only on frequency range and direction:

FR2 carries a larger overhead fraction because beam-management reference signals and wider control regions eat more of the grid; uplink is lighter than downlink because it carries no SSB and less control. The other two constants — the maximum code rate and the symbol duration — are fixed by the design of the code and the numerology:

R_max = 948/1024 is the top entry of the NR MCS/CQI code-rate design — it caps how little redundancy the LDPC code may add, so it sets the bits-per-RE ceiling. Note that T_s already averages the 14 symbols of a slot across a 1 ms subframe, which is why the same slots-per-second falls out as 2μ · 1000.

Method A — fully worked

Take a single FR1 carrier: 100 MHz, μ = 1 (30 kHz subcarrier spacing), N_PRB = 273, 4 layers, 256QAM (Q_m = 8), f = 1, downlink so OH = 0.14.

The intermediate values are worth tabulating, because the same six lines apply to any configuration — only the inputs change:

That 2.34 Gbps is a peak: it assumes the full band, the top modulation, all four layers busy, the maximum code rate, and only the flat overhead discount. Aggregate more carriers (increase J) and the rates simply add — carrier aggregation is why the formula is a sum over j.

Method B — actual throughput from TBS

The realistic figure is built from the Transport Block Size the scheduler actually assigns, per the procedure in TS 38.214 §5.1.3.2. Instead of the flat overhead of Method A, you count the resource elements that survive DMRS and configured overhead in the scheduled PRBs, then apply the real code rate and modulation from the MCS table.

Walking the chain term by term:

• N_symb — the OFDM symbols allocated to PDSCH in the slot (up to 14).
• N_DMRS — the REs per PRB spent on demodulation reference signals (e.g. 12 for one DMRS symbol, more with additional DMRS positions).
• N_oh — the higher-layer configured overhead (xOverhead: 0, 6, 12 or 18 RE/PRB), reserving room for CSI-RS, control, and rate-matched signals.
• The per-PRB usable REs are capped at 156 (that is 12 × 13, the ceiling used even if a slot exposes more).
• Multiply by allocated PRBs to get N_RE; multiply by code rate R, modulation order Q_m and layers v to get the information bits N_info.
• The standard's quantisation and (for larger blocks) LDPC-segmentation rounding turn N_info into the final TBS.

The quantisation is not hand-waving. For small blocks (N_info ≤ 3824) the standard rounds to the nearest entry of a fixed TBS table so the size aligns with the LDPC base-graph and byte boundaries; for larger blocks it quantises N_info to a granularity that lets the transport block divide cleanly into LDPC code-block segments, each within the maximum code-block size. That is why the worked TBS below lands a few hundred bits above the raw N_info — it is snapped up to the nearest valid, segmentable size.

Crucially, R and Q_m here are not pinned to the maximum. They come from the MCS index the gNB's link-adaptation loop selected to hold a target block-error rate for the measured channel — typically an initial-transmission BLER around 10%. That single design choice is the largest reason Method B sits below Method A.

Method B — worked and contrasted

Take one PRB slice of a scheduled PDSCH: N_symb = 12 symbols, N_DMRS = 12 RE/PRB (one DMRS symbol), N_oh = 6, single layer, an MCS giving 256QAM (Q_m = 8) and code rate R = 0.92578, over N_PRB = 273, μ = 1.

Scale to 4 layers and the single-slot figure lands in the ~2 Gbps range — close to Method A, because we deliberately chose the top MCS and near-full allocation. Drop the MCS, shrink the allocation, add control overhead, or admit a 10% BLER and the gap opens up. That is the whole point of the contrast:

Why is actual always ≤ peak? Real overhead exceeds the flat discount, the scheduler rarely fills every PRB of every slot, link adaptation picks an MCS below the maximum to hold the BLER target, and that ~10% BLER itself shaves throughput. Peak is the ceiling; Method B is the room you actually live in.

UE capability, peak-rate bounds & carrier aggregation

The Method A number for a real device is not open-ended — it is capped by what the UE told the network it can do. During capability signalling the UE reports, per band and per band-combination, the parameters that feed straight into the formula: the maximum number of MIMO layers, the highest supported modulation (which fixes Q_m), the supported bandwidth (which fixes N_PRB), and the scaling factor f. Multiply those out across the reported carriers and you have the UE's advertised peak. The network can schedule at or below that bound but never above it.

Carrier aggregation is exactly the outer sum Σj. Each aggregated component carrier contributes its own fully independent per-carrier rate — its own bandwidth, numerology, layers, and modulation — and the totals add. Two identical 100 MHz / 30 kHz / 4-layer / 256QAM carriers roughly double the single-carrier peak:

The same additivity holds for Method B: per-carrier TBS values are summed the same way. The table below shows how the peak scales with the configuration levers — each row is Method A with only the noted inputs changed:

Notice the FR2 row: despite a very wide subcarrier spacing and the same 100 MHz, the RB count is small (66) and the heavier OH = 0.18 plus a lower practical modulation pull the peak well below the FR1 case. Bandwidth and layers dominate the ceiling; numerology mostly moves latency, not peak rate.

Peak vs practical — where the bits go

Between the Method A ceiling and the throughput a user sees sits a stack of reductions, each with a physical cause. It helps to picture them as a waterfall: you start at the peak and every real-world effect subtracts a slice.

The four cuts, in order:

• SINR → MCS. A cell-edge UE cannot decode 256QAM at R_max; link adaptation drops it to a lower modulation and code rate so the block error stays near target. Lower Q_m · R means fewer bits per RE directly.
• BLER & retransmissions. Even at the chosen MCS, roughly 10% of first transmissions fail and are recovered by HARQ. Retransmissions consume slots that could have carried new data, so effective throughput is scaled by (1 − BLER) and further by soft-combining efficiency.
• Scheduling. The gNB shares the cell among many UEs. Any one UE gets a fraction of the PRBs and only some of the slots; control regions, SSB, and other UEs claim the rest.
• Counted overhead. Real DMRS, CSI-RS, and xOverhead often exceed the flat 14% that Method A assumes, especially with additional DMRS positions for high mobility.

Summary

There are two right answers to "how fast is 5G," and the trick is knowing which one you are quoting. Method A (TS 38.306) is the capability ceiling: one closed-form sum over carriers, flat overhead OH, fixed R_max = 948/1024, and no errors. It sizes UE categories, transport links, and datasheets, and a real device caps it at whatever its capability signalling advertised. Method B (TS 38.214) is the realised rate: count the REs that survive DMRS and xOverhead, apply the scheduled MCS's real Q_m and R, quantise to a valid TBS, multiply by slots-per-second (2μ·1000) and by (1 − BLER).

Method B is always ≤ Method A, and the gap is structural, not error. Walk the waterfall to explain any real number: counted overhead exceeds the flat fraction, link adaptation backs the MCS off the maximum to hold ~10% BLER, the scheduler gives one UE only a share of the PRBs and slots, and the BLER fraction itself is lost to retransmission. On a good FR1 100 MHz cell that compounds to roughly 40–70% of peak. Carrier aggregation adds carriers in both methods — it is literally the Σj — and numerology mostly buys latency, not peak rate, because more slots-per-second are offset by proportionally shorter symbols.

Quick Q&A