PDSCH — Physical downlink shared channel — the data
Channels — what carries what
Where it sits
What it is
PDSCH is the physical downlink shared channel — the physical realisation of the DL-SCH transport channel, and the carrier of essentially everything the network sends you. It is defined in TS 38.211 clause 7.3.1.
Count the downlink physical channels and the claim stops sounding like a slogan. TS 38.211 clause 7.3 has exactly three, and no more.
| Channel | Clause | Carries | Size | Its job |
|---|---|---|---|---|
| PBCH | 7.3.3 | The master information block | Fixed: 4 symbols, 20 blocks, ~56 bits | Bootstrap — readable by a device that knows nothing |
| PDCCH | 7.3.2 | Downlink control information | Fixed set of sizes, tens of bits | Pointing — where and how to receive the next thing |
| PDSCH | 7.3.1 | DL-SCH and PCH transport blocks | 24 bits to 1 572 272, decided per slot | Carrying — all of it |
So a picture of a slot is mostly a picture of PDSCH.
Three things in that picture are the whole idea of PDSCH.
It is not a fixed region. Nothing reserves those blocks for device A. The next slot may give the same blocks to somebody else, or to nobody.
Two devices are on it at once, on different settings. One allocation is 256QAM on four layers, the other 64QAM on two, in the same slot on the same carrier — because the two radio links are not equally good and the standard never asks them to pretend otherwise.
The reference signal is inside the allocation, not around it. A device is given the means to demodulate its own data within the resources it was given, and nothing is transmitted for the benefit of devices that are not being scheduled.
Why it is called shared
"Shared" is doing real work in that name, and it is the design decision the rest follows from. The resources are owned by nobody. They are reassigned from scratch every slot — as often as every 125 µs at 120 kHz subcarrier spacing — by a scheduler in the base station whose decision is announced in a DCI and never negotiated.
Compare it with the alternative to see what is being bought. A dedicated channel — a slice of spectrum held open for one device — is the right design when traffic is a constant stream, as a telephone call was. It is the wrong design for everything a phone does now: a burst of a few megabytes while a page loads, then seconds of nothing.
A fixed slice is wrong twice over. It is too small during the burst, so the page loads slowly while the rest of the carrier lies idle; and it is wasted during the silence, when the device has nothing to send and no other device may use its slice.
Sharing converts idle time into somebody else's peak. The price is that every single transmission must be announced — a PDSCH cannot be found by looking in a known place, because there is no known place — and that is exactly why PDCCH exists, and why a device wakes up to decode candidate control messages before it knows whether anything is there for it.
What actually arrives on it
Between an application and an antenna there are two renamings, not one, and mixing them up is the usual source of muddle.
Logical channel → transport channel. What kind of information is this? becomes how shall it be carried? Done by MAC. TS 38.300 clause 6.2.3.
Transport channel → physical channel. How shall it be carried? becomes which resource elements? Done by the physical layer. TS 38.202 clause 5.2.
The five logical channels are five different things, not five spellings of one. BCCH, PCCH, CCCH, DCCH and DTCH are distinguished by the kind of information they carry — broadcast, paging, connectionless control, dedicated control, user traffic. Four of the five end up on PDSCH; each keeps its own name the whole way down, and each is defined separately in TS 38.300 clause 6.2.2.
| Logical channel | What kind of information | Transport channel | Physical channel |
|---|---|---|---|
| BCCH | The master information block | BCH | PBCH |
| BCCH | System information blocks, SIB1 onwards | DL-SCH | PDSCH |
| PCCH | Paging — "wake up, there is something for you" | PCH | PDSCH |
| CCCH | Control for a device with no RRC connection yet | DL-SCH | PDSCH |
| DCCH | Dedicated control — reconfiguration, measurement orders | DL-SCH | PDSCH |
| DTCH | The user's own traffic | DL-SCH | PDSCH |
PCH is the row worth a second look. It is a transport channel with its own name, its own sleep 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 coding specification says the same thing by its title: TS 38.212 clause 7.2 is called "Downlink shared channel and paging channel" — one chain, two transport channels.
And the physical layer never learns which of these it is carrying. What MAC hands down is a transport block: an opaque bag of bits with a length, and nothing else. TS 38.202 clause 4.1 states it in two lines — "a transport block is defined as the data delivered by MAC layer to the physical layer and vice versa". That opacity is why the design scales: add a service above, and the physical layer needs no change at all, because it never looked inside.
From a bag of bits to a picture on the grid
Eleven operations separate the transport block from the antenna, and they divide cleanly in two. The first six are TS 38.212 clauses 7.2.1 to 7.2.6 and know nothing about radio: bits in, bits out. The last five are TS 38.211 clause 7.3.1 and turn bits into a picture.
The figure follows one real transport block all the way down — device A from the slot above: 94 152 bits, 24 resource blocks, twelve symbols, four layers, 256QAM at a target code rate of 948/1024. Every number in it is computed, and the arithmetic closes at the bottom.
Four of those steps are worth knowing by name, because they answer a question a reader will otherwise keep asking.
Why is the block cut up at all? An LDPC decoder is built for a bounded block length; the largest BG1 code block is 8 448 bits. A 94 152-bit transport block cannot be decoded in one piece, so clause 7.2.3 cuts it into twelve, each with its own CRC. The per-block CRCs cost 288 bits here — 0.3 % — and buy the ability to tell which piece failed, which is what code block group retransmission later spends.
Where does the code rate actually come from? Not from the encoder. LDPC always emits its fixed-rate output — 304 128 bits here, more than three times the input. Rate matching reads a window out of a circular buffer and sends only what fits the allocation: 101 376 bits, giving an effective rate of 0.929. Change the MCS and nothing about the encoder changes; only the size of the window does.
Why is the data scrambled? So that a neighbouring cell's transmission, or another device's, looks like noise rather than like a plausible codeword. The sequence is seeded by the device's RNTI and the cell identity, so two devices scheduled on the same resources in adjacent cells cannot decode into each other.
Why does the arithmetic close? Because it was made to. The transport block size was computed from the allocation before any of this began, so that the codeword would exactly fill the resource elements that were set aside. Nothing in the DCI carries the size — both ends compute it, from the same inputs, and must reach the same answer.
How much fits, and what decides it
TS 38.214 clause 5.1.3.2 is the arithmetic, and it must give the same answer in the base station and in the device, from the same inputs, every time, with nothing signalled to confirm it.
Step 1 — count the resource elements. Per resource block, $N'_{\text{RE}} = 12 \cdot N^{\text{sh}}_{\text{symb}} - N^{\text{PRB}}_{\text{DMRS}} - N^{\text{PRB}}_{\text{oh}}$ — twelve subcarriers times the allocated symbols, minus what the reference signal takes, minus a configured overhead allowance. Then $N_{\text{RE}} = \min(156,\, N'_{\text{RE}}) \cdot n_{\text{PRB}}$. The cap of 156 is not a typo: a full slot holds $12 \times 14 = 168$ elements per block, and the sizing arithmetic deliberately never counts more than $12 \times 13$.
Step 2 — the honest number. $N_{\text{info}} = N_{\text{RE}} \cdot R \cdot Q_m \cdot \nu$: elements, times code rate, times bits per symbol, times layers. It is almost never the answer.
Steps 3 and 4 — quantise. Small blocks are rounded up to the nearest of 93 tabulated sizes between 24 and 3 824; large ones are rounded onto a power-of-two grid and then trimmed so the result divides evenly into code blocks.
The rounding looks like sloppiness and is the opposite. A retransmission need not use the same resources as the original — fewer blocks may be free, or a different MCS may be chosen — but it carries the same transport block, and combining the two only works if both ends agree on its length. A coarse ladder means a modest change in allocation lands on the same rung, and the two transmissions agree without any signalling that says so.
Read the vertical gap as the whole job of link adaptation. The scheduler's choice of MCS and rank is a choice among those four lines, and it is made from a CSI report that describes the channel as it was some milliseconds ago. Aim too high and the block fails; aim too low and most of the allocation is spent on redundancy nobody needed. The design target is a first-transmission failure rate of one in ten — a link that never failed would be running far below what the channel could carry.
What has to happen around it
A PDSCH is never alone. Four other things must happen around every single one, each on its own channel or signal, each with its own clause. Remove any one of them and the transmission cannot be received.
The acknowledgement is the part that makes the whole scheme workable. A device that fails to decode does not throw the attempt away: it keeps the soft information and combines it with the retransmission, which is sent from a different starting point in the same circular buffer, so the second attempt adds parity the first did not carry. Sixteen such conversations can be in flight at once, identified by a HARQ process number in the DCI.
And the deadline is real. TS 38.214 clause 5.3 gives the device a fixed budget, $N_1$, between the last symbol of the PDSCH and the first symbol of the acknowledgement. Past 120 kHz subcarrier spacing that budget is longer than a slot, so the acknowledgement can no longer be sent in the following slot at all — the numerology outran the silicon, and the standard admits it in a table.
What it is not
PDSCH is not a substitute for another channel. It is what LTE's downlink channels collapsed into. PCFICH, PHICH, PMCH and the always-on cell-specific reference signals were all deleted from NR; the jobs that survived the deletion moved onto PDSCH or into the DCI.
| Not PDSCH | What it is instead | How its position is known |
|---|---|---|
| PDCCH | The scheduling message that points at a PDSCH — control, never user data | Configured search spaces inside a CORESET; the device blind-decodes candidates |
| PBCH | The master information block, inside the SS/PBCH block | Fixed by the standard — it must be findable knowing nothing |
| PUSCH | The uplink mirror: same chain, opposite direction, one extra waveform option | Granted by a DCI, in the uplink |
| DL-SCH | Not a channel on the air at all — the transport channel PDSCH realises | — it has no position; it is a contract, not a picture |
The DL-SCH row is the one that trips people. DL-SCH and PDSCH are two names for two different levels of the same thing: DL-SCH is what is being carried and under what terms — a transport block, of a stated size, with HARQ, with a stated error target — and PDSCH is the resource elements that carry it this time. The transport channel is the contract; the physical channel is the mechanism.
Read on
The full treatment is nr-pdsch — a note of its own, in six parts, from the packet to the deadline. This page is the definition and the map reference; that note is where the subject is developed and where every claim here is derived.
| To go deeper on… | Read |
|---|---|
| The three downlink channels, and what "shared" costs | The channel that carries everything |
| The fall through SDAP, PDCP, RLC and MAC | Coming from where |
| What LTE had that NR deleted, and the PUSCH mirror | A substitute for what |
| The two CRCs, the two base graphs, the segmentation rule | The coding chain, step by step |
| The circular buffer, and what a retransmission really sends | The circular buffer |
| Scrambling, the five constellations, layers and ports | From codeword to resource element |
| DM-RS positions, and everything else carved out of the allocation | What rides alongside |
| The DCI fields: time domain, frequency domain, and blind decoding | The DCI that schedules it |
| The transport block size in four steps, with a worked example | How big is it? |
| CQI, the MCS tables, and why the mapping between them is not standardised | What the scheduler is aiming at |
| The peak rate formula, and what the constant 0.14 hides | How fast can it go |
| Sixteen HARQ processes, the $N_1$ budget, the round trip drawn to scale | HARQ, and the deadline |
Sideways, to the concepts this page leaned on: transport channel · logical channel · transport block · resource block · transport block size · DM-RS · DCI · PDCCH · LDPC · rate matching · modulation · layer · HARQ · RNTI · link adaptation
Before this concept, the hierarchy says to learn the following — the full chain, in order: