The downlink shared channel, from the packet to the antenna

Open a web page on a phone. Somewhere a server sends an IP packet, and a few milliseconds later those bytes are in the phone's memory. In between, the packet was cut up, numbered, ciphered, headed, error-protected, encoded, punctured, scrambled, mapped to constellation points, spread across antennas, painted onto a grid of subcarriers, and radiated.

Almost all of that happened on one channel. It is called the physical downlink shared channel, PDSCH, and it is defined in TS 38.211 clause 7.3.1 — four pages, in a document of several hundred.

In one line. PDSCH is the physical realisation of one transport channel, the DL-SCH. Everything the network sends you that is not the four-symbol block you used to find the cell, and not the scheduling message that pointed at the data, arrives on PDSCH. It is not a substitute for another channel; it is what the other downlink channels of LTE were collapsed into.

How to read this note. Like its two predecessors, it is a ladder and gets harder in one direction only. Part I is plain words and needs nothing but the idea of a radio. Part VI is the reading list. Every fact carries a clause number, so you can check it, and every number that was calculated rather than quoted shows its working.

What you should already have. The frame-structure note built the resource grid — subcarriers, symbols, the block of twelve, bandwidth parts, and what an antenna port means. This note takes all of that as given and asks what actually travels on it.

The channel that carries everything

Three channels down, and only one of them is yours

Count the downlink physical channels in the standard. Not the signals — the channels, the things that carry information handed down from a higher layer. TS 38.211 clause 7.3 has exactly three subclauses:

That is the whole list. PBCH gets you into the cell, PDCCH tells you where to look, and everything else in the downlink — every web page, every video frame, every system information block after the first, every paging message, every RRC reconfiguration — is PDSCH.

What "shared" means, and why it is in the name

The word is doing real work. A shared channel is one whose resources are not owned by anybody and are reassigned from scratch on every transmission opportunity.

The alternative, for contrast. A dedicated channel gives a device a fixed slice of the radio for the duration of a call. That was how circuit-switched cellular worked, and it is efficient exactly when traffic is a constant-rate voice stream and nothing else.

Data traffic is not that. It is bursty by nature: idle for seconds, then a hundred megabits in a hurry. A fixed slice is either far too small during the burst or wasted during the silence.

So NR gives the grid to a scheduler in the base station, which reassigns it every slot — as often as every 125 µs at 120 kHz subcarrier spacing. TS 38.300 clause 6.2.1 lists what the DL-SCH transport channel supports, and the list is essentially a description of a shared resource:

Every one of those bullets is a knob the scheduler turns per transmission. PDSCH is the surface those knobs act on.

The whole thing on one page

Before any of the detail, here is the shape of it. A PDSCH is never alone. Four other things must happen around it, and every one of them is a separate channel or signal with its own clause:

Coming from where — the fall through the stack

The layers above, in the order a byte meets them

A packet does not arrive at the physical layer as a packet. It arrives as an anonymous block of bits, and by then five sublayers have had their turn.

The handover point is a transport block, and nothing else

This is the sentence to remember, and TS 38.202 clause 4.1 states it in two lines:

"The physical layer offers data transport services to higher layers. The access to these services is through the use of transport channels via the MAC sub-layer. A transport block is defined as the data delivered by MAC layer to the physical layer and vice versa." — TS 38.202 clause 4.1

A transport block is an opaque bag of bits with a length. The physical layer does not know whether it holds a video frame or a signalling message, and it does not care. Everything in Parts II and III of this note operates on that bag.

That opacity is the whole reason the design scales. Add a new service above — a new QoS class, a new type of signalling — and the physical layer needs no change at all, because it never looked inside.

Two mappings, not one

Between an application and an antenna there are two renamings, and confusing them is the usual source of muddle.

PCH is worth a second look. It is a separate transport channel with its own name, its own DRX behaviour and its own clause — and it has no physical channel of its own. TS 38.202 clause 5.2.3 disposes of it in one sentence: "The PCH is carried on PDSCH." The same is visible in the coding specification, whose clause 7.2 is titled "Downlink shared channel and paging channel" — one chain, two transport channels (TS 38.212 clause 7.2).

A substitute for what

Three different questions hide inside that one, and they have three different answers.

It is the physical realisation of DL-SCH

Within NR, PDSCH substitutes for nothing. It is not an alternative to another channel; it is what a transport channel becomes when it stops being an abstraction and starts being energy.

The relationship is worth stating precisely, because the two names are used loosely everywhere:

What it replaced: LTE's downlink channel zoo

This is the historical answer, and it is the interesting one — because NR's downlink is radically shorter than LTE's, and PDSCH is where several of the deleted channels went.

Count the clauses. LTE's physical layer specification lists seven downlink physical channels (TS 36.211 clauses 6.4 to 6.9, including 6.8A/6.8B/6.8C). NR lists three (TS 38.211 clause 7.3).

The pattern is one idea applied seven times: stop transmitting things nobody asked for.

PCFICH, PHICH and CRS were all always-on. They cost energy and spectrum in an empty cell, they made the carrier impossible to reshape, and — the reason that eventually forced the issue — they made it impossible to turn a cell down. A base station whose CRS must be radiated across the whole band every subframe cannot sleep.

NR's rule is the opposite: nothing is transmitted unless it is for somebody, with the single unavoidable exception of the SS/PBCH block, which is what a device with no knowledge finds first. Everything else was either deleted or absorbed into a scheduled PDSCH.

So the honest answer to "a substitute for what" is: PDSCH is what four LTE downlink channels became when the design stopped reserving the radio in advance. It did not replace them one for one; it swallowed the jobs that survived, and the rest were dropped.

Its mirror: PUSCH

The uplink has the same structure, one letter different: PUSCH carries UL-SCH, defined in TS 38.211 clause 6.3.1 with almost the same processing chain, and coded by TS 38.212 clause 6.2.

The differences are all consequences of who is transmitting:

The coding chain, step by step

MAC hands down one transport block of $A$ bits. Six operations later it is a codeword: a flat sequence of $G$ bits sized to fit exactly the resource elements the scheduler set aside. Those six operations are TS 38.212 clauses 7.2.1 to 7.2.6, in that order, and they are the same six for DL-SCH and for PCH.

The CRC, and why there are two of them

Error detection comes first, before any correction. The entire transport block is used to compute parity bits which are appended to it (clause 7.2.1):

The split is an overhead argument, and the numbers make it obvious. On a 100 000-bit block, 24 bits of CRC is 0.024 %. On a 200-bit block — a paging message, a small acknowledgement — 24 bits is 12 %, and 16 bits is 8 %. The standard buys back four percentage points on exactly the blocks where the percentage hurts, and accepts the weaker check because a short block is also less likely to hide an error.

This CRC is not the error correction. It is the verdict. After the LDPC decoder has done its work, the CRC is what decides whether the block is delivered upwards or a retransmission is asked for. TS 38.202 clause 4.2 lists them as separate physical-layer functions: "error detection on the transport channel and indication to higher layers" and "FEC encoding/decoding of the transport channel".

Two LDPC codes, not one

NR does not have an LDPC code. It has two base graphs, and clause 7.2.2 chooses between them with a rule that fits on one line:

Read the rule as a two-dimensional selection: BG2 is for short blocks and for low rates; BG1 is for everything large and fast. The two are genuinely different codes, not one code with a parameter:

Why two codes and not one. A code has to be punctured upwards from its mother rate to reach a high rate and repeated downwards to reach a low one, and both operations cost performance the further you push them. One code covering QPSK-at-1/8 and 1024QAM-at-0.93 would be badly matched at both ends.

Splitting the range in two halves the distance any one code has to be stretched. BG2's lower mother rate ($\approx 0.19$ against $0.32$) is exactly what a coverage-limited transmission needs, and its smaller matrix is cheaper to decode — which matters because the coverage case is also the case where the device is far away and short of power.

Segmentation, and why 8448

A transport block can be three quarters of a million bits long (§9.2). No LDPC decoder is built for that. So clause 7.2.3 cuts it up:

8448 is not a round number, and that is the clue. It is $22 \times 384$, and 384 is the largest lifting size $Z_c$ in Table 5.3.2-1. So the maximum code block is not a design target picked for its own sake — it is whatever the largest permitted expansion of base graph 1 happens to hold. The same is true of BG2: $10 \times 384 = 3840$.

The cost of segmentation is 24 bits per code block, and it is the price of parallelism. A decoder can work on all $C$ code blocks at once, and — more importantly — a code block that decodes correctly need never be sent again (§5.3). Without the per-block CRC there would be no way to know which ones those were.

Encode, rate match, concatenate

The last three steps are quick to state and are where the rate finally becomes what the scheduler asked for.

The circular buffer, and what a retransmission really is

Four starting points around one buffer

The encoder's output is written into a buffer and read out from one of four positions. Those positions are the redundancy versions, and the DCI selects one with two bits.

Now the important part, and it is easy to miss. The first $2 Z_c$ systematic bits are never written to the buffer at all — clause 5.3.2 starts the output at $k = 2 Z_c$. So $rv_0$, the version that starts at position 0, does not begin at the start of the message. It begins two lifting sizes in.

A device that receives only $rv_0$ therefore has a punctured systematic block, not a clean copy of the data. The two missing columns are the most heavily connected in the base graph, and the decoder is expected to reconstruct them from parity. This is deliberate — it raises the effective rate of the first transmission at no cost in buffer — and it is the single most surprising line in the whole chain.

What the retransmission sends

Because the four versions start at four different places, a retransmission is not a repeat.

Limited-buffer rate matching is the constraint made explicit. Clause 5.4.2.1 sets $N_{\text{cb}} = \min(N, N_{\text{ref}})$ with $N_{\text{ref}} = \lfloor \text{TBS}_{\text{LBRM}} / (C \cdot R_{\text{LBRM}}) \rfloor$ and $R_{\text{LBRM}} = 2/3$ — and for PDSCH it is always on ($I_{\text{LBRM}} = 1$, clause 7.2.5). The buffer is therefore sized so a receiver only ever has to store enough soft bits for an effective rate of 2/3, not for the code's full length. The circular buffer is truncated to fit the cheapest receiver the standard is willing to allow.

Code block groups — retransmitting less than everything

A 770 000-bit transport block is 92 code blocks (§9.2). If one of them fails, resending all 92 wastes the other 91.

TS 38.214 clause 5.1.7 allows the code blocks to be gathered into code block groups, with one acknowledgement bit each, so only the failed groups are retransmitted. The number of groups is configured, not derived, and the trade is plain: more groups means finer retransmission and more feedback bits on the uplink.

This is the feature LTE could not have. LTE acknowledged a whole transport block with a single bit on PHICH (§3.2) — a dedicated channel with a fixed, tiny capacity. Once the acknowledgement moved onto PUCCH as an ordinary variable-size payload, spending several bits per block became possible, and partial retransmission followed. Deleting a channel is what made the feature affordable.

From codeword to resource element

Six paragraphs of specification turn $G$ bits into complex numbers on antenna ports. They are clauses 7.3.1.1 through 7.3.1.6, and each one is short enough to quote.

Scrambling — why your neighbour's data looks like noise

Before modulation, every bit is added modulo 2 to a pseudo-random sequence (clause 7.3.1.1). The sequence generator is initialised with

This is not encryption — the sequence is public and the RNTI is sent in the clear. It does two engineering jobs:

Modulation — five constellations

Layer mapping, and why there are two codewords

The modulation symbols are dealt out across layers — up to eight — by Table 7.3.1.3-1. The mapping itself is trivial: round-robin. The interesting part is the codeword count.

Two codewords exist because eight layers are not equally good. Spatial multiplexing produces streams of very different quality; forcing them all to one modulation and code rate means the good ones are wasted and the bad ones fail. Two codewords let the scheduler run the strong half hard and the weak half gently, and retransmit only the half that broke.

They stop at two because feedback is expensive. Eight codewords would mean eight acknowledgements and eight MCS fields in every DCI, for a gain that shrinks with each split.

Antenna port mapping — the clause that does nothing

Clause 7.3.1.4 is the shortest in the chain, and the most revealing. In full, the mapping from layer $x^{(\lambda)}$ to antenna port $y^{(p)}$ is:

Where is the precoding? In LTE it is right here: TS 36.211 clause 6.3.4 is a full clause with sub-clauses for transmit diversity, for large-delay cyclic delay diversity, and — clause 6.3.4.2.3 — a codebook of precoding matrices that both ends must agree on.

NR has none of it in the physical-channel specification, and the omission is the design:

NR downlink precoding is transparent. The base station applies whatever precoder it likes, and it applies the same precoder to the demodulation reference signals as to the data. The device never learns what the matrix was, does not need to, and estimates the effective channel — precoder and propagation together — from the DM-RS.

That is why the mapping clause is an identity, and why the LTE precoding clause has no NR counterpart. The codebook that survives in NR is on the reporting side only (TS 38.214 clause 5.2.2.2, the PMI), where it is a compressed hint from the device about what the base station might want to do — a suggestion, not a contract.

The practical consequence is large. The number of physical antennas at the base station is invisible to the device: it sees layers and ports. A 64-element array and a 4-element one look identical from the phone's side, which is what let massive MIMO be deployed without touching the device specification.

Virtual blocks, physical blocks, and the interleaver

The symbols are mapped, in increasing order of subcarrier and then symbol, into the virtual resource blocks assigned for transmission (clause 7.3.1.5). Virtual blocks then become physical ones (clause 7.3.1.6):

The interleaver buys frequency diversity for allocations too small to have any. A four-block allocation sitting in one place is at the mercy of whatever that part of the channel is doing; the same four blocks scattered across a hundred megahertz will not all fade at once. It is worth having precisely when the scheduler cannot pick a good place — for a first transmission to a device it has no channel information about, which is why format 1_0 in a common search space is the case with its own rule.

What rides alongside, and what is carved out

An allocation of resource blocks is not all data. Some resource elements inside it carry reference signals, and some are reserved for other things entirely. Both are subtracted before the transport block size is computed (§9), so this section is a prerequisite for that one.

DM-RS — the reference signal that replaced always-on

Demodulation reference signals are known symbols placed inside the allocation so the receiver can estimate the channel it must invert. They are defined in TS 38.211 clause 7.4.1.1, and their position is the first thing to understand about a PDSCH allocation.

Two decisions define the pattern, and both are configured, not fixed.

Additional positions are a Doppler setting wearing a different name. One reference symbol per slot is enough if the channel is the same at the end of the slot as at the beginning. At walking speed it is. At 300 km/h on a high band it is not, and the estimate from symbol 2 is stale by symbol 13. Every additional position costs a symbol's worth of payload in every resource block, and buys the ability to interpolate across the slot.

This is where LTE's cell-specific reference signals went (§3.2). CRS was transmitted across the whole carrier, every subframe, forever, whether or not anybody was being scheduled, because it had to serve any device that might be listening. DM-RS is transmitted only inside an allocation, only when there is an allocation, and is precoded with the data it demodulates (§6.4).

The consequence is that an idle NR cell radiates almost nothing, and a busy one spends its reference-signal overhead only where there is something to demodulate.

The rest of the furniture

All of this is subtracted, not punctured. The specification's phrase is that the elements are "not available for PDSCH": the codeword is sized to fit what is left, rather than being written over the top and damaged. That distinction is what makes the transport block size arithmetic of §9 exact rather than approximate.

The DCI that schedules it

PDSCH carries no information about itself. There is no header on it, no length field, no identifier. A device that stumbled on one would have no way to know it was there. Everything needed to receive it arrives first, on a different channel, in a message called downlink control information.

The message, and how a device knows it is theirs

A DCI is a short bit string carried on PDCCH. It is encoded with a Polar code, and its CRC is masked with the RNTI of the intended recipient (TS 38.212 clause 7.3.2). There is no address field: a device tries the RNTIs it owns, and the one that makes the CRC check out is the answer.

Look at what the 44 bits are spent on. Four fields describe the transmission — where, when, how big, how coded. Six are about the acknowledgement and the retransmission machinery. A downlink assignment is more than half a conversation about what happens if it fails.

Time: the slot, the start symbol, and the two mapping types

The four-bit time field is a row index into a table configured by RRC. The row supplies three things (TS 38.214 clause 5.1.2.1): the slot offset $K_0$, a combined start-and-length value, and the mapping type.

The start and length arrive as one number, packed by a rule that is worth reading because it looks arbitrary and is not:

The mapping type is the more consequential half of the row, and it is the difference between a slot-shaped world and a symbol-shaped one:

Type B is the feature LTE did not have, and it is why NR can claim low latency at all. In LTE a downlink transmission was a subframe: one millisecond, aligned to a grid, whether you had a megabyte or a hundred bytes to send. In NR a transmission can be two symbols starting at symbol 9 — at 120 kHz subcarrier spacing that is about 18 µs, and it does not have to wait for the next slot boundary to begin.

Note that S = 3 for type A is only allowed when dmrs-TypeA-Position is pos3 (Table 5.1.2.1-1, Note 1). The allocation cannot start after its own reference signal.

Frequency: a bitmap or a range

Two schemes, and the choice is between flexibility and precision (clause 5.1.2.2).

The cost comparison is concrete. On a 273-block bandwidth part — 100 MHz at 30 kHz subcarrier spacing:

Two bits fewer, ten times the frequency resolution, and no ability to skip a hole. That is the whole trade, and resourceAllocation set to dynamicSwitch lets the DCI choose per transmission.

How big is it? Transport block size

Everything so far has described a container. TS 38.214 clause 5.1.3.2 decides what fits in it — and it must produce the same answer in the base station and in the device, from the same inputs, every time, with no negotiation.

The four steps

The cap of 156 in step 1 is worth a sentence. A resource block has $12 \times 14 = 168$ elements in a full slot, and 156 is $12 \times 13$ — one symbol's worth held back. The count used for sizing is therefore never the whole slot, no matter how the allocation is configured.

A worked example

Take an ordinary high-end downlink: 100 MHz at 30 kHz subcarrier spacing — 273 resource blocks — four layers, twelve allocated symbols, one front-loaded DM-RS symbol with both CDM groups declared without data, no configured overhead, and MCS index 27 from table 2 (256QAM, $R = 948/1024$).

Check it yourself. The whole of clause 5.1.3.2 is about twenty lines of Python. This implements steps 1 to 4 and the segmentation rule of TS 38.212 clause 5.2.2.

from math import floor, ceil, log2

def tbs(NRE_prb, nPRB, R, Qm, v):          # TS 38.214 clause 5.1.3.2
    NRE   = min(156, NRE_prb) * nPRB                       # step 1
    Ninfo = NRE * R * Qm * v                               # step 2
    if Ninfo <= 3824:                                      # step 3
        n  = max(3, floor(log2(Ninfo)) - 6)
        Np = max(24, 2**n * floor(Ninfo / 2**n))
        return next(t for t in TABLE_5_1_3_2_1 if t >= Np)
    n  = floor(log2(Ninfo - 24)) - 5                       # step 4
    Np = max(3840, 2**n * round((Ninfo - 24) / 2**n))
    if R <= 0.25:      C = ceil((Np + 24) / 3816)
    elif Np > 8424:    C = ceil((Np + 24) / 8424)
    else:              return 8 * floor((Np + 24) / 8) - 24
    return 8 * C * floor((Np + 24) / (8 * C)) - 24

print(tbs(12*12 - 12, 273, 948/1024, 8, 4))    # -> 1080480

Ties in the round of step 4 are broken towards the next largest integer, which Python's banker's rounding does not do; it makes no difference to these two cases but will to others.

Why it is quantised at all

Step 2 already produced a number. Steps 3 and 4 throw precision away — 768 580 becomes 769 832 — and the reason is §12.

What the MCS index actually buys

Five bits of MCS select a row from one of four tables, and each row is a pair: modulation order and target code rate. Their product per resource element is the spectral efficiency, and it is tabulated in the specification alongside them.

The tables overlap deliberately. Table 4's index 22 and table 2's index 27 are the same point — $Q_m = 8$, $R = 948/1024$, 7.4063 bits per element. The 1024QAM table did not extend the range at the bottom; it spent codepoints at the top and gave up resolution everywhere else, which is why it is configured only when the link can actually use it.

What the scheduler is aiming at

Everything in §9 started from $Q_m$, $R$ and $\nu$ as givens. They arrive in the DCI — but the scheduler had to choose them, and it chose them from a number the device sent up some milliseconds earlier. That number is the channel quality indicator, and its definition is the reason this section belongs in a note about PDSCH rather than in one about CSI.

The definition is written in terms of PDSCH

TS 38.214 clause 5.2.2.1 does not define CQI as a signal-to-noise ratio, a received power or any other physical quantity. It defines it as a statement about a hypothetical PDSCH:

Read what the device is being asked. Not how good is the channel but "what is the largest PDSCH you could have decoded?" The answer is expressed in the same currency as the thing being scheduled, which is why the scheduler can act on it directly.

The 0.1 is the most consequential constant in the whole system, and it is easy to read past.

The device reports the highest index that decodes with at most a 10 % block error rate. So the link is deliberately operated at a point where one transmission in ten fails. That is not a tolerance; it is a target.

Why aim to fail? Because the alternative is worse. Choosing an MCS that never failed would mean choosing one far below what the channel can carry, and paying that margin on every transmission for the sake of the rare bad one. Running at 10 % and repairing the failures with incremental redundancy (§5.2) is cheaper, provided repair is cheap — and Parts II and V are, between them, the machinery that makes it cheap.

This is the sentence that explains why HARQ exists. HARQ is not a safety net bolted on in case something goes wrong. It is a load-bearing part of the rate selection, and without it the whole link would have to be run several decibels more conservatively.

Four tables, and the one that changes the target

Four bits of CQI index four rows of a table, and which table is in force is configured by cqi-Table in CSI-ReportConfig:

Table 3 is URLLC, and it is worth seeing what "ultra-reliable" costs in this currency. Moving from table 1 to table 3 at the same reported index gives up roughly a factor of four in rate at the bottom of the ladder — and buys four orders of magnitude in block error rate. The reliability is bought with spectral efficiency, in a table, in advance.

The mapping from CQI to MCS is not in the standard

Here is the gap that surprises people. 3GPP specifies the CQI tables. It specifies the MCS tables. It never specifies how to get from one to the other.

And yet the two ladders were plainly built to line up. Compare their spectral-efficiency columns:

The CQI ladder is the MCS ladder with every other rung removed. Fifteen CQI values sample twenty-eight MCS values, and the missing odd rungs are the finer steps the scheduler may use but the device is not asked to report.

So why leave the conversion out? Because a scheduler should not use it verbatim, and 3GPP knows it.

A CQI report is stale by the time it is acted on, it describes a reference resource rather than the actual allocation, and it is a prediction the device made about its own receiver. The universal practice is outer-loop link adaptation: take the CQI, convert it with the table correspondence above, then add an offset that is nudged down on every NACK and up on every ACK, so that the measured block error rate converges on the 10 % the CQI definition assumed.

That loop is where vendors differ, and leaving it unspecified is what lets them differ. The specification fixes the vocabulary and the target; the control law is a product decision. The outer-loop technique itself is standard engineering rather than a 3GPP requirement — see the books in §15.2.

How fast can it go

§9.2 produced 2 161 Mbit/s from one slot of one carrier. Every advertised 5G number is that calculation done again with different assumptions, and there is a specification that fixes the assumptions so the numbers can be compared: TS 38.306 clause 4.1.2, the formula a device uses to declare what it can do.

The formula everybody quotes

Every factor is something this note has already met. $Q_m$ is §6.2. $v_{\text{Layers}}$ is §6.3. $R_{\max} = 948/1024$ is the top row of the MCS tables. $N_{\text{PRB}} \cdot 12$ is subcarriers, and $T^{\mu}_s$ is the symbol duration from the frame-structure note. The only new thing is $\text{OH}$ — and it is the interesting one, because it is a constant.

What the constant 0.14 is hiding

Run the formula on exactly the configuration of §9.2 — 273 blocks, 30 kHz, four layers, 256QAM — and it returns 2 337 Mbit/s. The slot-level calculation returned 2 161. The formula is 8 % more optimistic, and the whole difference is in $\text{OH}$.

$2/14 = 0.1429$, and the specification prints $0.14$. The advertised peak rate assumes one symbol of control and one symbol of reference signal, and nothing else — no additional DM-RS position, no PT-RS, no CSI-RS, no SSB overlap, no xOverhead, and a control region one symbol deep. Each of those is a real configuration this note has already described, and each one takes the real number further below the quoted one.

This is not a criticism of the formula. A capability declaration has to be reproducible from a handful of numbers a device can state in advance, so the overhead must be a constant. But it means the quoted figure is a ceiling under favourable bookkeeping, and the gap between it and a measured throughput is not a fault — it is the configuration.

Reaching the target

The number 5G was asked to hit predates all of this. TR 38.913 clause 7.1 — the requirements study that framed the work — sets it:

One PDSCH on one 100 MHz carrier delivers 2.3 Gbit/s. So the target is a factor of about nine away, and the formula shows exactly where the nine comes from:

Look at the fourth row. Eight aggregated carriers, four layers, 256QAM — a genuinely extravagant configuration — lands at 18.7 Gbit/s, 6 % short. That near miss is the best single argument for why the later releases went where they did: 1024QAM (Release 17, MCS table 4) and eight-layer downlink reception are each, by themselves, enough to close it.

And spectral efficiency tells the same story from the other side. Four layers of 256QAM over 100 MHz is 23.4 bit/s/Hz against the 30 bit/s/Hz target of TR 38.913 clause 7.2. Eight layers gives 46.7. The target was never reachable by modulation alone — the missing factor is spatial, which is why §6.3 and the CSI machinery behind it matter more to peak rate than any constellation does.

HARQ, and the deadline the phone must meet

Every PDSCH is provisional. It is delivered upwards only if the CRC checks; otherwise the device must say so, and say so by a deadline the standard fixes in symbols. This last part is about that deadline, because converting its units turns a scheduling parameter into a statement about silicon.

Sixteen conversations at once

A single stop-and-wait exchange would idle the link for a whole round trip after every block. So the device runs many in parallel, each with its own buffer and its own state:

Asynchronous, and that is the difference from LTE. A retransmission arrives whenever the scheduler chooses, identified by its process number, on an ordinary PDCCH assignment. LTE's downlink HARQ was synchronous in the uplink direction and needed PHICH to carry the acknowledgement at a fixed time (§3.2). Making it asynchronous deleted a channel and made the scheduler free.

$N_1$ — the number that looks like symbols

The device must have its acknowledgement ready by a time TS 38.214 clause 5.3 defines exactly:

Table 5.3-1 gives $N_1$ for processing capability 1. Read it as printed and it looks like the phone is being given more time as the numerology grows — 8 symbols at 15 kHz, 160 at 960 kHz. Convert the symbols to microseconds and the opposite is true, up to a point, and then something stops.

The last three rows are identical to the last decimal place, and they are not a coincidence. Past $\mu = 3$ the table has stopped being a table:

Check it yourself. Six lines, using the symbol duration from TS 38.211 clause 4.1 and $N_1$ from TS 38.214 Table 5.3-1.

from fractions import Fraction as F
Tc = F(1, 480000 * 4096); k = 64             # TS 38.211 clause 4.1
N1 = {0: 8, 1: 10, 2: 17, 3: 20, 5: 80, 6: 160}   # TS 38.214 Table 5.3-1
for mu, n in N1.items():
    sym = float((F(2048 * k, 2**mu) + F(144 * k, 2**mu)) * Tc) * 1e6
    print(mu, f"{sym:7.2f} us x {n:3d} = {sym * n:7.2f} us")

It prints 570.83, 356.77, 303.26, 178.39, 178.39, 178.39.

The round trip, drawn to scale

Put the deadline back into a slot and it becomes a picture. Everything below is already established: a two-symbol CORESET, PDSCH filling the rest of the slot, the decoding budget from Table 5.3-1, and an acknowledgement that can only be sent at a slot boundary at or after the budget expires.

Compare that with what was asked for. TR 38.913 clause 7.5 sets the user-plane latency target at 4 ms for eMBB and 0.5 ms for URLLC, each direction. Those are end-to-end layer-2 figures and include more than one physical-layer exchange, so the comparison is indicative rather than exact — but the shape of the answer is visible in the figure:

What the flat line means

The method, which is worth more than the answer. This is the same move as the previous note's guard period: a requirement written in symbols that is really a requirement in microseconds. When a specification expresses a constraint in units that do not naturally fit it — a silence measured in symbols, a decoding deadline measured in symbols — the number will do something strange as the units change, and converting them finds the physical fact underneath. There, it was a switch settling. Here, it is a decoder running.

What each release added

PDSCH has been in every release since the first. Reading what was added to it is a good way to see what the design turned out to be short of — and the specifications record this themselves, in a detail that is easy to miss.

The parameter names carry their own dates

A 3GPP parameter introduced after Release 15 keeps a suffix naming the release that introduced it. mcs-Table-r17 was added in Release 17. csi-InferencePrediction-r19 in Release 19. This is not documentation convention; it is how the specification distinguishes a new field from the Release 15 field of the same name, and it means the release history is greppable:

cd ~/Documents/md-engine/"Courses (RAW)/5G Topics"
pdftotext -layout ts_138214v190400p.pdf - | grep -oE '[a-zA-Z][A-Za-z0-9-]+-r1[6-9]' | sort -u

Every row of the table below was found that way, then read in context.

Release 19 asks the device to predict

The last row deserves its own paragraph, because it changes the kind of thing a report is.

Everything in §10 rests on a measurement of the past. The device measures a reference signal, reports what it saw, and the scheduler acts on it some milliseconds later — by which time, if anything is moving, the channel has changed. That staleness is the permanent tax on the whole arrangement, and no amount of faster reporting removes it; it only makes it smaller.

Release 19 attacks it differently. TS 38.214 clause 5.2.2.2 now contains "Enhanced Type II codebook for predicted PMI" (clause 5.2.2.2.10) and its port-selection twin (5.2.2.2.11), and the procedure text says plainly:

Read that twice. The device is not reporting the channel. It is reporting a sequence of precoders for slots that have not happened yet, and the standard declines to say how it should arrive at them.

That silence is the same silence as §10.3 — 3GPP fixes the vocabulary and leaves the algorithm to the implementer. But the thing being left open is now a prediction of a time series, which is a materially different kind of gap, and the obvious way to fill it is a learned model running in the device.

This is where this note touches layer 4 of the folder. The projects tracker's AI-RAN layer asks which decision, at which timescale, on which interface. Here is one concrete answer, in a clause number: the decision is the precoder, the timescale is a few slots, and the interface is the CSI report. Not a slogan — a field in CSI-ReportConfig.

The limits, and what comes after

Three walls

Everything this note measured runs into one of three limits, and it is worth naming them together because the next generation's proposals are aimed at exactly these.

What is being proposed after this

The framework document. The successor system is defined, so far, by ITU-R Recommendation M.2160 (November 2023), "Framework and overall objectives of the future development of IMT for 2030 and beyond" — the IMT-2030 counterpart of the IMT-2020 framework whose requirements became TR 38.913. It names six usage scenarios and a set of capabilities, of which the ones bearing on PDSCH are peak and experienced data rate, spectral efficiency, latency, reliability, and two that are new: integrated sensing and integrated AI. Not checked against a copy here — it is not in the archive.

What that implies for the three walls, stated as directions rather than as facts:

The 3GPP study on this is TR 38.843, Study on artificial intelligence (AI)/machine learning (ML) for NR air interface. Its three studied use cases are CSI feedback compression, beam management, and positioning — and the first of those is the direct ancestor of csi-InferencePrediction-r19. It is not in the archive (it has no ETSI-transposed copy at the path the other documents came from), so it is cited here as a pointer and nothing in this note depends on it.

Where this note stops, and the others begin

Each wall hands off to a different part of this folder, which is the argument for the folder's four-layer shape.

Sources, and where to read more

The clauses this note stands on

They are text PDFs, so every claim above can be checked from a terminal:

cd ~/Documents/md-engine/"Courses (RAW)/5G Topics"
pdftotext -layout ts_138212v190400p.pdf - | grep -n -A6 "LDPC base graph selection"
pdftotext -layout ts_138214v190400p.pdf - | grep -n -A4 "PDSCH processing time for PDSCH processing capability 1"
pdftotext -layout ts_138202v190000p.pdf - | grep -n "PCH is carried on"
pdftotext -layout ts_136211v190300p.pdf - | grep -n "^6\.[4-9] "

Where to read around it

How to check a fact in this note

The same two-minute habit as the previous two notes:

1. Find the claim and read the clause number beside it.
2. Open the document and go to that clause.
3. If the note and the standard disagree, the standard is right.
4. If a number is calculated rather than quoted, the calculation is shown as code you can run — §9.2 and §12.2 are both worked examples, and §13.1 is a one-line grep.
5. One section is fenced off on purpose. §14.2 is the only part of this note not backed by a frozen clause, and it says so at the top. If you are checking facts, check that one hardest — or skip it, since nothing else depends on it.

The section-number warning applies here too. This page numbers its own sections, and so does 3GPP. "§9.2" is a section of this page; a 3GPP clause is always written with its document, as "TS 38.214 clause 5.1.3.2". Never a bare clause number.

Where this goes next

§14.3 already handed each of the three walls to a layer of this folder. What follows is the same thing said as a reading order, with the specific number each next note has to explain.

What to take away, if only one thing. PDSCH looks like a large subject and is actually a small one wrapped in a lot of configuration. Strip the options away and it is: cut the block up so a decoder can manage it, encode each piece with more parity than you need, send as much of that parity as the channel can carry, and keep the rest in a buffer in case you were wrong.

Everything else in this note — four MCS tables, four CQI tables, two base graphs, two resource allocation types, two mapping types, four redundancy versions, sixteen HARQ processes — is the machinery for being wrong cheaply. And §10.1 is the proof that this is deliberate rather than defensive: the standard asks the device to report the highest rate that fails no more than one time in ten. A shared channel is not a pipe. It is a standing bet, placed every slot, at odds the specification chose.