PDCCH Blind Decoding — CCE, Aggregation & Search Spaces in 5G NR

1. Why Blind Decoding Is Unavoidable

There is no downlink pointer. Nothing in NR tells a UE where its grant is before the grant arrives, because any such pointer would itself have to be found first, and the problem would only move. The UE therefore starts every monitoring occasion knowing four things it needs and not knowing any of them: which aggregation level the gNB chose, which candidate position within that level, which DCI size, and whether anything was transmitted to it at all.

It resolves this by guessing exhaustively. For every candidate in its list, at every DCI size it has been configured to expect, it demodulates the coded bits, runs a polar decoder, de-masks the CRC with each RNTI it owns, and checks the CRC. A CRC pass means this candidate carried a DCI for me. A CRC fail means nothing in particular -- noise, an empty candidate, or a perfectly good DCI addressed to a different UE. The UE cannot tell which, and does not need to.

1.1 What the alternative would cost

Consider the design that avoids blind decoding: a fixed grant location per UE, signalled once at RRC setup. UE 1 always reads CCEs 0-1, UE 2 always reads CCEs 2-3, and so on. The UE then performs exactly one decode per occasion, and the whole of this document evaporates. It also breaks the cell in three separate ways:

Table 1. Why the fixed-location design is not merely inelegant. The hashing function in section 4 exists to give the scheduler freedom in all three dimensions at the price of decode attempts at the UE.

So the negotiation is explicit and it runs in both directions. The scheduler wants many candidates at many aggregation levels in many occasions, because each one is a degree of freedom. The UE wants few, because each one is a polar decode that must finish before the PDSCH it points at has been buffered. TS 38.213 clause 10.1 is where that negotiation is written down, and every limit in it is a limit on the UE's effort, enforced by the UE, invisible to the network.

1.2 What invokes this machinery

Blind decoding is not a procedure that starts and finishes. It runs continuously at every monitoring occasion the UE has, for as long as the UE is in RRC_CONNECTED Active Time -- and also in RRC_IDLE and RRC_INACTIVE, where the UE blind-decodes the paging search space for P-RNTI at every paging occasion. What varies is the candidate list, and it is recomputed:

• Every slot, because the hashing recursion advances with the slot number -- the same configuration produces different CCE positions in consecutive slots (section 5).
• Every monitoring occasion within a slot, because the budget is consumed per slot (Rel-15) or per span (Rel-16), and a second occasion in the same slot competes with the first.
• At every BWP switch, because the CORESETs change, N_CCE,p changes, and therefore every candidate position changes. See the companion 30 CORESET and Search Space document for the configuration side.
• At every C-RNTI change -- initial access, handover, re-establishment -- because the C-RNTI is the seed of the hashing recursion. A new C-RNTI relocates the UE's entire candidate set.
• At SCell activation or deactivation, because the per-cell budget is apportioned across configured serving cells (section 14, and the companion 29 Carrier Aggregation document).
• At search space set group switching (Rel-16) and after PDCCH skipping (Rel-17), both of which change which search spaces have occasions at all without any RRC message.

2. What a Candidate Is, Exactly

A PDCCH candidate is a run of L control channel elements at consecutive CCE indices within one CORESET, at one monitoring occasion. L is the aggregation level and takes the values 1, 2, 4, 8 and 16. That is the whole definition, and three details in it are load-bearing.

Table 2. The three properties of a candidate that the arithmetic in the rest of this document depends on. The third is the one that surprises people, and section 5.4 works through what aliasing actually does to the candidate set.

2.1 Candidates per occasion, and where the number comes from

For one search space set s at one occasion, the candidate count is simply the sum of the five nrofCandidates values. Nothing scales it, nothing deduplicates it, and a candidate at an aliased position still counts:

candidates(s) = M_s,1 + M_s,2 + M_s,4 + M_s,8 + M_s,16

  nrofCandidates ::= SEQUENCE {
      aggregationLevel1   ENUMERATED {n0,n1,n2,n3,n4,n5,n6,n8},
      aggregationLevel2   ENUMERATED {n0,n1,n2,n3,n4,n5,n6,n8},
      aggregationLevel4   ENUMERATED {n0,n1,n2,n3,n4,n5,n6,n8},
      aggregationLevel8   ENUMERATED {n0,n1,n2,n3,n4,n5,n6,n8},
      aggregationLevel16  ENUMERATED {n0,n1,n2,n3,n4,n5,n6,n8}
  }

  worst case per search space set: 8 + 8 + 8 + 8 + 8 = 40 candidates
  which alone exceeds M_max,slot at every numerology except 15 kHz
  (44) -- and even there it leaves 4 for every other search space.

The enumeration deserves a second look. The values are n0, n1, n2, n3, n4, n5, n6 and n8 -- note that n7 does not exist, and note that a single search space set can legally be configured with 40 candidates, which is more than the entire per-slot budget at 30 kHz. The ASN.1 will not stop you. The UE will not report the problem. What happens instead is section 10.

3. The Candidate-to-CCE Mapping, In Full

This is the formula that turns configuration into CCE indices. It is worth reading twice, because every symbol in it is doing something and the nesting of the two mod operations is easy to get wrong TS 38.213 cl. 10.1:

The CCEs of PDCCH candidate m at aggregation level L, for search space
set s in CORESET p, in slot n:

                  /                                             \
   L  x   |  Y            +  floor( m x N_CCE,p )  +  n_CI  | mod  N_CCE,p
          |   p,n            (       L x M_max,p )          |      ------
                  \                                             /      L

        +  i          for  i = 0, 1, ... L-1

  written linearly:

    CCE(m,i) = L * ( ( Y_p,n
                       + floor( m * N_CCE,p / (L * M_max,p) )
                       + n_CI
                     ) mod floor( N_CCE,p / L )
                   ) + i

  N_CCE,p    total CCEs in CORESET p at this occasion
  M_max,p    nrofCandidates at level L for THIS search space set
             (the spec writes it M^(L)_s,max)
  m          candidate index, 0 .. M_max,p - 1
  n_CI       carrier indicator field value, 0 without cross-carrier
  Y_p,n      the hash (section 4). Zero for a common search space.
  i          which CCE within the candidate, 0 .. L-1

Listing 1. The candidate-to-CCE mapping. The inner floor(m x N_CCE,p / (L x M_max,p)) spreads the M candidates evenly across the CORESET; the outer mod floor(N_CCE,p / L) wraps them into the CORESET; the x L at the front aligns the result to an aggregation-level boundary.

3.1 Reading it as three independent stages

The formula composes three separable operations, and separating them makes hand-verification tractable.

Table 3. Stage 1 is common to every UE with the same configuration. Only stage 2 is per-UE, and only stage 2 changes from slot to slot. This is why two UEs with identical nrofCandidates have identically shaped candidate sets in different rotations.

3.2 What the formula does not depend on

Three omissions are worth stating, because each one is a thing engineers reasonably expect to matter and it does not:

• The DCI format and size. Candidate positions are identical whether the UE is looking for a 41-bit DCI 1_0 or a 60-bit DCI 1_1. The size is a separate axis of the search, multiplying the number of decode attempts without changing where they happen (section 9).
• The symbol within the slot. Y_p,n is indexed by slot, not by occasion. Two monitoring occasions of the same search space set in the same slot -- symbol 0 and symbol 7, say -- compute the same candidate CCE indices. They differ only in which OFDM symbols carry them, which matters for the CCE count in section 8 but not for the hash.
• Anything the gNB signals per-slot. There is no per-slot candidate hint, no DCI that says look here next time. Both ends compute the same positions independently from configuration that both already have, which is exactly why a C-RNTI mismatch is undetectable.

4. The Hashing Function, Term by Term

Y_p,n is the only per-UE, per-slot quantity in the mapping, and it is produced by a linear congruential recursion seeded with the UE's own RNTI TS 38.213 cl. 10.1:

  UE-specific search space set:

      Y_p,n  =  ( A_p  x  Y_p,n-1 )  mod  D

      Y_p,-1 =  n_RNTI               (the C-RNTI, and must be non-zero)
      D      =  65537                (a prime, 2^16 + 1)
      A_p    =  39827   for  p mod 3 = 0
                39829   for  p mod 3 = 1
                39839   for  p mod 3 = 2

      p      =  controlResourceSetId of the CORESET the search space
                set points at
      n      =  slot index within the frame, n_s,f^mu

  Common search space set:

      Y_p,n  =  0        for all p and all n

4.1 Why the hash is seeded with the RNTI

Because the alternative is coordination, and coordination costs signalling that would itself need a PDCCH. If every UE computed the same candidate positions, then in a CORESET with 8 AL2 positions the first eight UEs scheduled in a slot would collide with each other constantly, and the gNB would have to arbitrate every occasion explicitly. Seeding with n_RNTI scatters each UE's candidate set to a rotation of the CORESET that no other UE is likely to share, with no signalling at all -- both ends already know the C-RNTI, so both ends can compute the same rotation independently.

The corollary is the sharpest diagnostic in this document. The C-RNTI is an input to the address calculation, not just a label. If the UE and the gNB disagree about the C-RNTI by even one bit, they compute different Y_p,n and the UE searches a completely different rotation of the CORESET. Nothing detects this. The gNB transmits a valid PDCCH at a candidate position the UE never examines; the UE finds nothing at positions the gNB never used. Both sides are behaving correctly and the UE is simply unreachable. The event to look for is a C-RNTI change that one side applied and the other did not -- most often around handover (companion 22 Handover Overview) or contention resolution (companion 03 Random Access).

4.2 Why it advances every slot

Because a static per-UE rotation would make collisions permanent. Two UEs whose rotations happened to coincide would collide in every slot forever, and one of them would be systematically starved of AL2 candidates for the lifetime of the connection. Advancing the recursion once per slot means a collision in slot n says nothing about slot n+1: the pair of UEs re-randomises against each other 2000 times a second at 30 kHz. A collision becomes a transient loss of one scheduling opportunity rather than a persistent capacity fault.

4.3 Why A_p depends on the CORESET index

Three multipliers, selected by p mod 3, so that a UE monitoring two CORESETs does not get correlated rotations in both. Without this, the same Y would apply to every CORESET and a UE unlucky in CORESET 1 would be unlucky in CORESET 2 in the same slot -- exactly the correlation the design is trying to break. With three multipliers the rotations in CORESETs 1 and 2 are effectively independent.

It also means something practical for hand-verification: you cannot reuse a computed Y across CORESETs. A UE with controlResourceSetId 1 and 2 has two separate recursions running, with multipliers 39829 and 39839, both seeded from the same C-RNTI. Getting this wrong is the commonest error when reconstructing a candidate set by hand from a configuration dump.

4.4 What n_CI does

n_CI is the value of the carrier indicator field in the DCI, and it is zero in every configuration without cross-carrier scheduling. When CrossCarrierSchedulingConfig is present and a cif-InSchedulingCell value is assigned, the scheduling cell's CORESET carries grants for several cells, and n_CI shifts the candidate positions per scheduled cell. The effect is that the candidates for SCell 2 and SCell 3, monitored in the same CORESET on the PCell, sit at different rotations rather than on top of each other.

Table 4. n_CI in the mapping formula. It is the CIF value, not the presence of the field, and it is the mechanism by which one CORESET can serve several serving cells without the candidate sets piling up. See the companion 29 Carrier Aggregation document for the CIF configuration itself.

4.5 Why the common search space uses Y = 0

Because that is the entire point of a common search space. A SI-RNTI-addressed DCI, a paging DCI, a RAR grant, a slot format indication -- these are addressed to a set of UEs, and the set members have different RNTIs or, in the case of a UE that has not yet been assigned one, no RNTI at all. There is no per-UE seed available, and if there were, using it would make the message unfindable by everyone except one UE.

So Y_p,n = 0 for common search spaces, the rotation term vanishes, and the candidate positions reduce to the spread pattern alone. Every UE monitoring that search space set with the same nrofCandidates computes identical CCE indices, in every slot, for the life of the cell. That is what makes it common.

5. Worked: Two Slots, Four Aggregation Levels, One RNTI

The configuration below is carried through the whole document. It is the same UE and the same CORESET as the traces in section 20, so any number here can be checked against any number there.

Table 5. The reference configuration. N_CCE,p = 16 is small enough to hand-check and large enough to show real aliasing behaviour at AL8 and AL16.

5.1 The hash, three slots

That last table is where the interesting behaviour lives. Y changes dramatically from slot to slot -- 25259 to 47761 -- but the mapping only consumes it modulo floor(N_CCE,p / L), and at AL8 that modulus is 2. A 16-bit hash reduced modulo 2 is a coin flip, and at AL16 it is reduced modulo 1, which is not even that.

5.2 Slot n: the candidate positions

5.3 Slot n+1: the same configuration, different CCEs

5.4 The high-aggregation-level degeneracy

At AL8 in a 16-CCE CORESET there are two positions and the configuration asks for two candidates. The spread offsets are 0 and 1, and adding a hash modulo 2 permutes them. So the set of AL8 candidates is {CCE 0-7, CCE 8-15} in every slot, for every UE, forever. Only the labels m = 0 and m = 1 swap. At AL16 it is worse: one position, one candidate, no randomisation whatsoever.

The general rule: the hashing function randomises usefully when M_p,L is small relative to floor(N_CCE,p / L), and degenerates as the two approach each other. At AL1 with 6 candidates in 16 positions there is real freedom. At AL8 with 2 candidates in 2 positions there is none. This is one of several reasons a CORESET sized for AL16 -- 32 CCEs or more -- behaves qualitatively better under load than a 16-CCE one, even at the same total capacity per slot.

6. Candidate Collisions Between UEs

Two UEs collide when a CCE that one UE's candidate occupies is also occupied by a candidate of the other, at the same occasion, and the gNB wants to schedule both. It cannot: a CCE carries one PDCCH. So one of the two UEs is not scheduled in that occasion, and the loss is a PDCCH blocking event rather than a decoding failure.

6.1 The birthday framing

The right intuition is the birthday problem, not a per-pair collision probability. With P = floor(N_CCE,p / L) positions at aggregation level L and k UEs each needing one candidate at that level, the probability that all k get distinct positions is the familiar falling factorial, and it collapses much faster than people expect:

That last caveat is what makes nrofCandidates worth spending budget on. A UE with one AL2 candidate is blocked whenever that one position is taken. A UE with six is blocked only when all six are taken, which under moderate load essentially never happens. The candidate count is a blocking-probability knob, and it is the only one the configuration offers.

6.2 A real collision, computed

Take a second UE in the same cell, C-RNTI 0x5A2F = 23087, monitoring the same search space configuration on the same CORESET.

Two things to take from that. First, the overlap is large -- four of six -- and this is normal, not unlucky: with 8 positions and 6 candidates each, two UEs must share at least four. Second, the overlap changes membership every slot, so no particular candidate is chronically unavailable to either UE. The hashing function does not prevent collisions; it prevents them from being persistent.

6.3 What the gNB does about it

Every scheduler implementation has a CCE allocator that runs after the per-UE scheduling decisions and before PDCCH assembly. The details are not specified, but the shape is forced by the arithmetic:

1. Compute each selected UE's candidate CCE sets for this occasion, at the aggregation level link adaptation asked for.
2. Order the UEs -- typically by priority, then by constrainedness: a UE needing AL8 has two positions and must be placed before a UE needing AL1 with sixteen.
3. Place each UE greedily into a free candidate. On failure, either drop the UE from this occasion or retry at a lower aggregation level if the link budget allows it.
4. Any UE still unplaced is not scheduled in this occasion. Its data waits for the next one, which is a fresh rotation of every candidate set.

Table 6. Distinguishing candidate collisions from the failure modes they resemble. Collision loss scales with load and leaves PDCCH BLER unchanged, which is the discriminator worth remembering.

7. The Two Per-Slot Budgets

There are two limits, they are independent, and a configuration can pass one and fail the other. Almost everyone remembers the first and forgets the second, which is why a configuration review that only checks candidate counts can still produce a UE that drops search spaces TS 38.213 cl. 10.1.

Table 7. The two budgets. They are enforced by the UE, per slot, per serving cell, and TS 38.213 Tables 10.1-2 and 10.1-3 give the values per numerology.

Table 8. Per-slot, per-serving-cell PDCCH monitoring limits. The 15-to-30 kHz row pair is the instructive one: M_max drops and C_max does not, because the two limits are bounding different hardware.

7.1 Why two limits and not one

Because they bound two different pieces of silicon on two different timelines. Channel estimation happens before the UE knows which candidates matter: the DMRS in a CORESET is spread across all of it, and the UE must estimate the channel over every CCE it might decode, in the few tens of microseconds between the CORESET symbols ending and the decoder needing input. Polar decoding happens afterwards and is a sequential-ish, iterative workload with a different bottleneck.

The distinction also explains the counting rules, which otherwise look arbitrary. Candidates are counted with multiplicity, because each one is a separate decode. CCEs are counted without multiplicity -- hence "non-overlapping" -- because two candidates sharing a CCE share its channel estimate. In Figure 1 the sixteen candidates cover 42 CCE-positions but only 16 distinct CCEs, so they cost 16 against C_max,slot and 16 against M_max,slot. Change nrofCandidates to AL8 n2 only and you cost 2 candidates and still 16 CCEs.

8. Counting Candidates and Counting CCEs

Both counts are easy to get wrong in the same two ways: forgetting that a search space set with two occasions in a slot is counted twice, and getting the definition of "non-overlapping" wrong. Here are both rules, precisely.

8.1 Counting candidates

M_slot = sum over every (search space set s, occasion o) pair in this
         slot of  ( M_s,1 + M_s,2 + M_s,4 + M_s,8 + M_s,16 )

  counted with multiplicity:
    - the same search space set at two occasions counts twice
    - two search space sets on the same CORESET count separately
    - a candidate that aliases onto another candidate's CCEs
      still counts (section 5.4)

  NOT multiplied by the number of DCI sizes. A candidate monitored
  at two DCI sizes is two decode attempts but ONE monitored candidate.
  The DCI size multiplier is bounded separately, by the four-size
  rule in section 9.

That last paragraph is the subtle one and it is worth being explicit about. M_max,slot = 36 at 30 kHz does not mean 36 decode attempts. It means 36 candidates, each of which may be attempted at up to four different DCI sizes, so the worst-case attempt count is considerably higher. The specification bounds attempts indirectly, by bounding sizes -- which is exactly why the four-size limit exists and why it is not negotiable.

8.2 Counting non-overlapping CCEs

Two candidates' CCEs are the same CCE for counting purposes only if all three of these match: the CORESET, the first symbol of the monitoring occasion, and the CCE index. Change any one and it is a separate CCE with a separate channel estimate.

Table 9. The non-overlapping rule. The second row is the one that bites: adding a second monitoring occasion in the same slot on the same CORESET duplicates the entire CORESET's CCE cost.

8.3 Both counts for the reference configuration

8.4 Configurations that pass one limit and fail the other

Both directions occur in real configurations, and they are diagnosed completely differently, so it is worth having a concrete example of each in mind.

9. The DCI Size Budget: Four Sizes, Three of Them C-RNTI

The number of DCI sizes the UE monitors on a serving cell is limited separately from the number of candidates, and the limit is small TS 38.212 cl. 7.3.1.0:

1. At most four different DCI sizes may be monitored per serving cell.
2. Of those, at most three may be sizes for DCI scrambled by C-RNTI.

The reason is the multiplier in section 8.1. Every extra size multiplies the decode attempts across the entire candidate set, and unlike candidates it does so without any corresponding gain in scheduling freedom -- the gNB does not gain a placement option from a fourth DCI size, it gains a message type. So the specification rations sizes hard and then goes to considerable lengths to make configurations fit.

9.1 Why sizes, and not formats

Because the UE decodes to a length, not to a format. A polar decoder needs to know how many bits it is producing before it starts; the format is then inferred from which search space the candidate was in, from the RNTI that de-masked the CRC, and from the format-identifier bit in the payload. Two formats of the same length cost one size and are disambiguated after the fact:

Table 10. What costs a size and what does not. Different RNTIs at the same payload size are free; the same RNTI at two payload sizes is not. This is the opposite of most engineers' first guess.

9.2 Size alignment and zero padding

The DCI sizes are not chosen; they fall out of the configuration. A DCI 1_0's frequency-domain assignment field is ceil(log2(N_RB x (N_RB+1) / 2)) bits wide, so it depends on the bandwidth part it was sized against. A DCI 1_1's field set depends on which optional features are enabled. The specification therefore defines an alignment procedure that runs in steps and pads or truncates until the budget is met:

Table 11. The size-alignment procedure, abridged. The last step is the one worth internalising: the specification's answer to too many sizes is to make a format lie about its bandwidth part, not to reject the configuration.

10. Overbooking, and the Search Space That Stops Being Monitored

A configuration can ask for more than the budget allows. The ASN.1 permits it, the gNB may send it, and the UE accepts it -- and then resolves the excess unilaterally, by not monitoring some of its search spaces. This is specified behaviour, not an error condition, and it is the single most important mechanism in this document TS 38.213 cl. 10.1.

10.1 The rule

1. Allocate candidates and non-overlapping CCEs to every common search space set with an occasion in this slot. Common search space sets are never dropped, whatever they cost -- the UE will exceed neither limit on their account, because the network is required not to overbook common search spaces in the first place.
2. Then consider the UE-specific search space sets in increasing order of searchSpaceId.
3. Allocate each one in turn, provided that doing so keeps both the running candidate total within M_max,slot and the running non-overlapping-CCE total within C_max,slot.
4. At the first UE-specific search space set that does not fit, stop. That set and every UE-specific set with a higher searchSpaceId is not monitored in this slot.

Read step 4 twice. It is not "drop candidates until it fits" and it is not "drop the candidates that do not fit". It is stop allocating, which abandons whole search space sets. A search space set that asks for twelve candidates when only three remain in the budget does not get three -- it gets zero, and so does everything above it.

10.2 A resolution, worked

Look at what was lost. searchSpaceId 3 was the only search space on CORESET 2 -- a different beam, a different part of the band -- so the UE has stopped monitoring that CORESET entirely. searchSpaceId 4 was the symbol-7 occasion, the whole reason the configuration existed: it was there to halve grant latency. Both are gone, and the configuration file still says they are configured.

10.3 Why this is the failure mode to memorise

Every other failure in this document leaves a trace somewhere. This one leaves nothing, on either side, and the reason is structural rather than an oversight:

Table 12. Why an overbooked configuration is silent at every layer that could plausibly detect it. The only reliable detection is arithmetic performed off-line against the configuration.

11. Inside One Decode Attempt

One candidate, one DCI size, one attempt. Five steps, all of which the UE performs without knowing whether there is anything there.

1. Collect the coded bits. L x 108 QPSK symbol pairs from the candidate's CCEs, demodulated using the channel estimate formed from the CORESET's DMRS. 108 bits per CCE: 6 REGs x 9 data resource elements x 2 bits, and PDCCH is always QPSK.
2. Descramble. The PDCCH bit sequence is scrambled with a Gold sequence initialised from pdcch-DMRS-ScramblingID (or the physical cell identity if that IE is absent) and, in a UE-specific search space with pdcch-DMRS-ScramblingID configured, from the C-RNTI as well TS 38.211 cl. 7.3.2.3.
3. Polar decode to A + 24 bits, where A is the DCI size being attempted. Successive-cancellation list decoding, with the CRC used inside the decoder to pick among the surviving paths.
4. De-mask and check the CRC. XOR the RNTI into the last 16 of the 24 CRC bits and check. Repeat for each RNTI the UE owns in this search space -- C-RNTI, CS-RNTI, MCS-C-RNTI, and in a common search space SI-RNTI, P-RNTI, RA-RNTI, SFI-RNTI as applicable.
5. Validate the payload. A CRC pass is necessary but not sufficient (section 12).

11.1 The CRC, and why it is 24 bits

PDCCH uses a 24-bit CRC, generated by the g_CRC24C polynomial, and it is attached to a payload that is typically 40 to 80 bits. So the CRC is a third to a half the size of the message it protects, which is an unusual ratio and entirely deliberate: it is not sized for error detection on a single block, it is sized for error detection across tens of thousands of speculative decodes per second (section 12).

Payload:   a_0, a_1, ... a_(A-1)              A = DCI size in bits
CRC:       p_0, p_1, ... p_23                 g_CRC24C over a_0..a_(A-1)

Transmitted sequence b_0 .. b_(A+23):

    b_k = a_k                                   for k = 0 .. A-1
    b_(A+j) = p_j                               for j = 0 .. 7
    b_(A+j) = p_j  XOR  x_rnti,(j-8)            for j = 8 .. 23

  where x_rnti,0 .. x_rnti,15 is the 16-bit RNTI, MSB first.

Worked, C-RNTI 0x4C11:
    0x4C11 = 0100 1100 0001 0001
    p_8  XOR 0    p_12 XOR 1    p_16 XOR 0    p_20 XOR 0
    p_9  XOR 1    p_13 XOR 1    p_17 XOR 0    p_21 XOR 0
    p_10 XOR 0    p_14 XOR 0    p_18 XOR 0    p_22 XOR 0
    p_11 XOR 0    p_15 XOR 0    p_19 XOR 1    p_23 XOR 1

  Six CRC bits are inverted for this RNTI; the other eighteen pass
  through. A UE de-masking with a different RNTI inverts a different
  subset and the CRC fails.

Listing 2. CRC attachment and RNTI scrambling. Note that the mask is a fixed XOR, not a permutation or an encryption -- there is no security property here at all, only addressing. Any UE can de-mask any DCI with any RNTI it cares to try.

11.2 Polar coding, and what the higher aggregation levels actually buy

The A + 24 bits go to a polar encoder with a mother code length N = 2^n, capped at 512 for downlink control, and are then rate-matched to E = 108 L bits TS 38.212 cl. 5.3.1. That cap has a consequence most treatments skip:

Table 13. Rate matching at each aggregation level. The qualitative break between AL4 and AL8 is real: below it you are buying code, above it you are buying power. Both help, but they help differently against fading and against interference.

12. False Alarms, and DCI That Passes CRC but Makes No Sense

A 24-bit CRC has a false-pass probability of about 2^-24 per attempt against random input. That is a small number. It is not small enough.

12.1 The arithmetic

Twenty-six seconds per UE is not a rounding error. It means that in any loaded cell, several times a second, some UE somewhere decodes a DCI that was never transmitted, out of noise, with a valid CRC and its own RNTI. The design has to survive that, and it does -- but only because of the validation layer in section 12.2, which is why that layer is part of the specification and not left to implementations.

12.2 What the UE does with a DCI that passes CRC

It checks whether the payload makes sense, and discards it if not. Some of these checks are explicit in the specification, some follow from field ranges, and all of them are performed before the DCI is acted on:

Table 14. The validation layer. Only the SPS row uses the phrase "as if the CRC had failed"; the others are ordinary field-range constraints, but the practical effect is the same -- the DCI is dropped and nothing is reported.

12.3 When a false alarm is not caught

The uncomfortable case is a false-alarm DCI whose random payload happens to be internally consistent. Every field is in range, the HARQ process exists, the allocation fits the BWP. Nothing rejects it, and the UE acts on it. What happens next depends on whether it decoded as a downlink assignment or an uplink grant:

Table 15. Uncaught false alarms. The uplink case is why PDCCH false-alarm rate is a real design constraint rather than an academic one: a phantom grant becomes interference in someone else's allocation.

13. Aggregation Level Selection, From the gNB Side

Everything so far has been about what the UE searches. The other half of the negotiation is the gNB deciding which candidate to use, and that decision is link adaptation for a channel with no HARQ, no modulation adaptation and no direct feedback.