The PDCCH tells each UE, in every subframe, where its downlink data is and when it may send on the uplink. No PDSCH or PUSCH can be scheduled without it. This page follows one DCI through the physical layer, from CRC attachment to the resource elements of the control region, and points to the srsRAN code that implements each step.

PDCCH is a physical channel that carries downlink control information (DCI) and it has characteristics as described below.

• Mapped to the first L OFDM symbols in every downlink subframe.
• Number of the symbols (L) for PDCCH can be 1,2, or 3. (This 'L' value is informed to UE by PCFICH)
• Number of the symbols for PDCCH is specified by PCFICH
• PDCCH carries DCIs and the DCI carries Transport format, resource allocation, H-ARQ information related to DL-SCH, UL-SCH and PCH.
• PDCCH also carries DCI 0 which is for UL Scheduling assignment (e.g, UL Grants).
• Multiple PDCCH are supported and a UE monitors a set of control channels.
• Modulation Scheme is QPSK.
• PDCCH is like HS-SCCH for HSDPA and PDCCH for R99, E-AGCH/E-RGCH for HSUPA
• Even though PDCCH has a lot of functions, not all of them are used at the same time so PDCCH configuration should be done flexibly.
• If you are interested in the detailed information mapping in this channel, refer to 6.8.1 of 36.211. Following is the initial descrition on this section.
• The physical downlink control channel carries scheduling assignments and other control information. A physical controlchannel is transmitted on an aggregation of one or several consecutive control channel elements (CCEs), where acontrol channel element corresponds to 9 resource element groups. The number of resource-element groups not assigned to PCFICH or PHICH is REG N . The CCEs availablein the system are numbered from 0 and N_CCE-1 , where N_CCE = floor(N_REG/9) . The PDCCH supports multiple formats as listed in Table 6.8.1-1. A PDCCH consisting of nconsecutive CCEs may only start on a CCE fulfilling imod n = 0 , where i is the CCE number.

The number of PDCCH symbols in the list above applies to carriers wider than 10 RB. 36.211 v19.3.0 Table 6.7-1 allows 2, 3 or 4 symbols when the carrier has 10 RB or fewer, so a 1.4 MHz cell always has at least two control symbols. A PDCCH is built from CCEs of 9 REGs each. PDCCH formats 0 to 3 use 1, 2, 4 or 8 CCEs, which carry 72, 144, 288 or 576 bits (Table 6.8.1-1).

Followings are the topics to be covered in this page.

• PDCCH Processing Chain
• CRC Attachment
• Channel Coding
• Rate Matching
• Multiplexing/Scrambling
• Modulation, Layer Mapping and Precoding
• Resource Element Mapping
• PDCCH Encoding in srsRAN
• PDCCH Decoding in srsRAN
• Reference

PDCCH Processing Chain

How does a DCI of a few dozen bits become QPSK symbols spread over the control region? It passes through a chain of seven steps. 36.212 defines the bit-level steps 1 to 3, and 36.211 defines the physical steps 4 to 7. The figure below shows the chain, and the sub-sections that follow take the steps in order.

In terms of Channel Process, PDCCH goes through following steps. In case of PDCCH, the most complicated (also the confusing process) would be related to Step (7). Refer to CCE Index Calculation/PDCCH Decoding/Blind Decoding for the detailed process of how each bits of PDCCH symbols find its place in canditate area. Also refer to PDCCH Resource Allocation, and refer to PDCCH Candidate and Search Space for basic terminologies related to PDCCH resource allocation.

If you want to look into the final result of PDCCH resource allocation in visualized form as well as data processing process, refer to Matlab : Toolbox : PDCCH page.

The PDCCH processing chain. Steps 1 to 3 are in 36.212 clause 5.3.3, and steps 4 to 7 in 36.211 clause 6.8. The bit and symbol names on each arrow match the ones used in the sub-sections below.

CRC Attachment

In LTE, PDCCH (Physical Downlink Control Channel) payloads use a 16-bit CRC for error detection (36.212-5.3.3.2). This design ensures the CRC not only provides error detection, but also implicitly encodes the target UE’s identity (the RNTI) and, if applicable, the chosen transmit antenna port. The CRC fails if a different RNTI or wrong antenna selection mask is assumed, preventing the UE from decoding control information not intended for it.

Overall procedure for CRC attachment for DCI can be summarized as bellow

• Compute 16-bit CRC over the PDCCH payload (A bits).
• Append these bits to form B = A + 16 total bits.
• If no antenna selection is used, XOR the 16 CRC bits with the RNTI (xrnti).
• If antenna selection is used (for DCI format 0), XOR the CRC bits with both RNTI (xrnti) and the antenna selection mask (xAS).
• Transmit the resulting bits c0, … cB-1 for the PDCCH.

Step 1 of the chain. A depends on the DCI format, and K = A + 16 because the CRC is always 16 bits.

Let A be the length of the PDCCH payload (a₀, a₁, …, a_A−1). The CRC bits (p₀, …, p₁₅) are computed over all A bits and then appended, giving a total of B = A + 16 bits (b₀, …, b_B−1).

Once the 16 parity bits are attached, these bits can be scrambled using the RNTI (x_rnti) and, optionally, an antenna-selection mask (x_AS). This ensures the CRC is tied to a specific RNTI (and UE Tx antenna selection if applicable).

CRC Attachment

The CRC generator polynomial from Section 5.1.1 is used to derive the 16-bit CRC (p₀ … p₁₅) over the payload a₀ … a_A−1. These are appended to form:

b₀, b₁, …, b_A−1, b_A … b_A+15

where b_A+i = p_i for i = 0..15.

Masking with RNTI

If UE Tx antenna selection is not enabled, the 16 CRC bits (bits b_A … b_A+15) are XOR-ed with the RNTI bits x_rnti,0 … x_rnti,15, where the MSB of the RNTI corresponds to x_rnti,0. (This is the point where RNTI do the most important role)

Formally:

c_k = b_k for k < A c_k = ( b_k + x_{rnti, (k − A)} ) mod 2 for k = A..(A+15)

This combines the CRC bits with the RNTI so that a receiver needs the correct RNTI to pass the CRC check.

When there is no UE Tx Antenna selection, CRC attachment and Masking goes as follows.

CRC masking without antenna selection. The 16 parity bits are XOR-ed with the 16 RNTI bits. The top row labels the last CRC bit a₁₅, where p₁₅ is meant.

Additional Mask for Antenna Selection

When UE Tx antenna selection is configured, an extra mask x_AS is applied — specifically for DCI format 0. In that case, each CRC bit b_A..A+15 is XOR-ed with both x_rnti and x_AS:

c_k = b_k for k < A c_k = ( b_k + x_{rnti, (k − A)} + x_{AS, (k − A)} ) mod 2 for k = A..(A+15)

The mask x_AS is defined in Table 5.3.3.2-1. For example, if UE port 1 is selected, x_AS might be <0, …, 0, 1>, meaning only the least significant bit of the CRC is toggled.

< 36.212-Table 5.3.3.2-1: UE transmit antenna selection mask.>

When there is UE Tx Antenna selection, CRC attachment and Masking goes as follows.

CRC masking with UE transmit antenna selection. The mask of 36.212 Table 5.3.3.2-1 is added on top of the RNTI. The top row again labels the last CRC bit a₁₅ instead of p₁₅.

NOTE :How 'A' is determined ?

In LTE, A represents the number of bits in the PDCCH payload (the DCI message) before the CRC is attached. Its exact size depends on the chosen DCI format and the number of bits needed to represent each field within that format (e.g., frequency allocation, modulation and coding scheme, HARQ process number, etc.).

Example: DCI Format 0

Consider a scenario where DCI format 0 is used for uplink grants. The payload might include the following fields:

• Frequency-domain resource allocation (e.g., 10 bits)
• Modulation and coding scheme (e.g., 5 bits)
• HARQ process number (e.g., 3 bits)
• New data indicator (1 bit)
• Redundancy version (2 bits)
• Transmission power control command for uplink (2 bits)
• … and possibly other fields depending on the specific system configuration.

Adding these up (except the variable fields in this example), you may end up with, say, 27 bits in total. In that case, A = 27. Once determined, a 16-bit CRC is appended, resulting in a final codeword of A + 16 bits (i.e., 27 + 16 = 43 bits).

The value A = 27 is a real case. DCI format 1A on a 10 MHz FDD carrier has 26 bits, and 26 is one of the ambiguous sizes of 36.212 Table 5.3.3.1.2-1, so one zero bit is appended. Format 0 is then padded to the same 27 bits, so the UE can decode both formats with one blind decoding attempt. The field list above is closer to format 1A than to format 0: format 0 has no HARQ process number and carries the redundancy version inside its 5-bit MCS field.

In the current 36.212 v19.3.0, the antenna selection mask applies to DCI format 0 and to DCI format 6-0A of LTE-M. Every other format uses the RNTI mask alone, so the RNTI is the only UE-specific part of the whole PDCCH chain.

• 16-bit CRC on every DCI : gCRC16(D) = D¹⁶ + D¹² + D⁵ + 1 (36.212 clause 5.1.1).
• CRC masked with the RNTI : a wrong RNTI makes the CRC fail.
• Antenna selection mask : only for DCI format 0 and 6-0A, only the last bit differs.

Channel Coding

In LTE, Downlink Control Information (DCI) messages on the PDCCH are channel-coded with a tail-biting convolutional code at rate 1/3 (36.212-5.3.3.3). The encoder has constraint length 7, so it holds six shift registers, and it starts from the last six input bits instead of an all-zero state.

Step 2 of the chain. The encoder turns the K bits into three streams of D = K bits each.

< Table 5.1.3-2 of TS36.212 >

The defailed breakdown are as follows:

• Input Bits (c₀, …, c_K−1) The PDCCH payload (after CRC attachment) forms a block of K bits, denoted c₀, c₁, …, c_K−1. These bits become the input to the tail-biting convolutional encoder.
• Tail-Biting Convolutional Encoder LTE’s DCI uses a rate-1/3 convolutional encoder with tail-biting initialization. That means:
• The encoder “wraps around” so that its end state matches its start state without adding extra tail bits.
• Each input bit c_k produces three output bits d⁽⁰⁾_k, d⁽¹⁾_k, d⁽²⁾_k.
• Output Bits (d⁽ⁱ⁾_k) Because it is a rate-1/3 code, for every one input bit, you get three output streams. Each stream d⁽ⁱ⁾ has exactly D = K bits, so the total number of coded bits is 3 × K. Symbolically, we write them as d⁽ⁱ⁾₀, d⁽ⁱ⁾₁, …, d⁽ⁱ⁾_D−1 where i = 0, 1, 2 and D = K.

After these coded bits are generated, they are passed on to the next step (rate matching) and then eventually mapped to the PDCCH resources. Tail-biting convolutional coding ensures minimal overhead while preserving robust forward error correction for DCI payloads.

NOTE : In essence it follows the same tail-biting convolutional procedure (rate 1/3) as used for the PBCH. The main difference is simply the input bit length and how those bits are processed or repeated for each channel. But the core “encode one bit → produce three output bits, with tail-biting to avoid appending extra tail bits” is identical. Refer to BCH channel coding for further details.

Rate Matching

The encoder output has 3K bits, but a PDCCH must fill exactly 1, 2, 4 or 8 CCEs. Step 3 bridges the two sizes. It follows 36.212 clause 5.3.3.4, which reuses the rate matching of clause 5.1.4.2 for all convolutionally coded channels.

Each of the three streams d⁽⁰⁾, d⁽¹⁾ and d⁽²⁾ first goes through a sub-block interleaver with 32 columns. The bits are written row by row, the columns are permuted with the pattern of Table 5.1.4-2, and the bits are read out column by column. The three interleaved streams are then placed one after another in a circular buffer.

The output takes E bits from the circular buffer, where E is the size of the PDCCH format: 72 bits per CCE. If E is smaller than the buffer, the last bits are never read, which is puncturing. If E is larger, the reading wraps around the buffer, which is repetition. With the A = 27 example, K = 43 and the buffer holds 129 bits. One CCE (72 bits) therefore punctures it to a code rate of about 0.6, and eight CCEs (576 bits) repeat it to a code rate of about 0.075.

• Sub-block interleaver : 32 columns, one per coded stream.
• Circular buffer of 3K bits : read until E bits are collected.
• E = 72 bits per CCE : the aggregation level sets the code rate.

Multiplexing/Scrambling

Up to this point, each DCI has been processed on its own. From step 4 onwards, all PDCCHs of the subframe are handled as one block. The UE therefore finds its own DCI only by knowing where the CCEs of its search space start. The figures below show the multiplexing and the scrambling.

Step 4 of the chain, 36.211 clause 6.8.2.

PDCCH multiplexing and scrambling. The bits of all PDCCHs are concatenated, and the block is scrambled with a Gold sequence initialised with c_init = floor(n_s/2) 2⁹ + N_ID^cell at the start of each subframe.

c(i) here is a Gold Sequence. If you are not familiar with the concept of a Gold Sequence, refere to GoldCode page.

Two details are not visible in the figure. The multiplexer inserts <NIL> elements so that each PDCCH starts on the CCE position that its search space expects (36.213 v19.4.0 clause 9.1.1). It also inserts them so that the block fills every REG that the PCFICH and the PHICH do not use. The scrambling sequence depends on the cell ID and the slot number, but not on the UE.

Modulation, Layer Mapping and Precoding

Steps 5 and 6 are short, because the PDCCH has no choice of modulation or of transmission scheme. Both follow from the cell configuration, and the UE knows them before it decodes a single DCI.

36.211 Table 6.8.3-1 allows QPSK only. A CCE of 72 bits therefore becomes 36 symbols, which fill 9 REGs of 4 REs each. Layer mapping and precoding follow clauses 6.3.3.1 and 6.3.4.1 for a single antenna port, or clauses 6.3.3.3 and 6.3.4.3 for transmit diversity. Clause 6.8.4 also requires the PDCCH to use the same antenna ports as the PBCH. A cell with two CRS ports therefore sends every PDCCH with SFBC, and a cell with four ports uses the four-port SFBC with frequency switching.

Resource Element Mapping

Step 7 is the most complex step of the chain. It decides where each symbol quadruplet goes in the control region, and the UE has to reverse it before it can try any PDCCH candidate. The CCE Index page follows the same step in detail.

36.211 clause 6.8.5 works on symbol quadruplets, one per REG. The quadruplets are first permuted with the same 32-column sub-block interleaver as step 3, applied to quadruplets instead of bits. They are then cyclically shifted by N_ID^cell, so that neighbouring cells place their CCEs differently. Finally, they are mapped subcarrier by subcarrier. For each subcarrier, all L control symbols are visited, and each free REG gets the next quadruplet.

The result is that the 9 REGs of one CCE are spread across the whole carrier. That gives each PDCCH frequency diversity, even at aggregation level 1. It also means that a CCE index is a logical position, not a place in the grid, which is why the search space is defined in CCEs.

• QPSK only : 36 symbols per CCE.
• Same antenna ports as the PBCH : single port or SFBC.
• Interleaved and cyclically shifted : REGs of one CCE spread over the carrier.
• CCE index is logical : the physical position depends on the cell ID and the PHICH and PCFICH layout.

PDCCH Encoding in srsRAN

If you are interested in this process at the source code level of the protocol stack, I would suggest you to look into the openSource srsRAN. Following APIs can be good places for you to start. This list is from the master-branch of the code that was downloaded on Oct 8,2021

•   srsran_rm_conv_tx() -> \lib\src\phy\fec\turbo\rm_conv.c
•   srsran_convcoder_encode() -> \lib\src\phy\fec\convolutional\convcoder.c
•   srsran_pdcch_dci_encode_conv() -> \lib\src\phy\phch\pdcch.c
•   srsran_pdcch_dci_encode() -> \lib\src\phy\phch\pdcch.c
•   srsran_scrambling_b_offset() -> \lib\src\phy\scrambling\scrambling.c
•   srsran_mod_modulate() -> \lib\src\phy\modem\mod.c
•   srsran_layermap_diversity() -> \lib\src\phy\mimo\layermap.c
•   srsran_precoding_diversity() -> \lib\src\phy\mimo\precoding.c
• srsran_regs_pdcch_put_offset() -> \lib\src\phy\phch\regs.c
•   srsran_pdcch_encode() -> \lib\src\phy\phch\pdcch.c

Read in the order of the chain, the names show which step each function covers. The functions in bold are the entry points. The function srsran_pdcch_dci_encode() attaches the CRC with the RNTI mask (step 1). It then calls srsran_pdcch_dci_encode_conv() for the convolutional encoder (step 2). The rate matching (step 3) is in srsran_rm_conv_tx(). The function srsran_pdcch_encode() handles the rest of the chain. It scrambles (step 4), modulates (step 5), and maps the layers and precodes for transmit diversity (step 6). Finally, srsran_regs_pdcch_put_offset() places the symbols in the REGs (step 7).

Two things may surprise a reader of the code. The rate matching file rm_conv.c sits in the turbo folder, although it handles the convolutional code. The paths also date from 2021. The LTE code has since moved to the separate srsRAN_4G repository, so the paths may differ in a newer copy.

• srsran_pdcch_dci_encode() : steps 1 to 3 for one DCI.
• srsran_pdcch_encode() : steps 4 to 7 for the whole control region.
• LTE code now in srsRAN_4G : the paths above are from the 2021 master branch.

PDCCH Decoding in srsRAN

If you are interested in this process at the source code level of the protocol stack, I would suggest you to look into the openSource srsRAN. Following APIs can be good places for you to start. This list is from the master-branch of the code that was downloaded on Oct 8,2021

•   srsran_crc_checksum() -> \lib\src\phy\fec\crc.c
•   srsran_bit_pack() -> \lib\src\phy\utils\bit.c
•   srsran_viterbi_decode_f() -> \src\phy\fec\convolutional\viterbi.c
•   srsran_rm_conv_rx() -> \lib\src\phy\fec\turbo\rm_conv.c
•   srsran_pdcch_dci_decode() -> \lib\src\phy\phch\pdcch.c
•   srsran_pdcch_decode_msg() -> \lib\src\phy\phch\pdcch.c

The receiver runs the chain backwards, but with one difference. The UE does not know the format, the aggregation level or the CCE position of its DCI. It therefore repeats the decoding for every candidate of its search space, which is the blind decoding step.

For each candidate, srsran_rm_conv_rx() undoes the rate matching, srsran_viterbi_decode_f() decodes the tail-biting code, and srsran_crc_checksum() recomputes the CRC over the decoded bits. The UE then XORs the received CRC with its own RNTI. If the result matches, the DCI is meant for this UE; if not, the candidate is discarded. The two functions in bold, srsran_pdcch_decode_msg() and srsran_pdcch_dci_decode(), drive this per-candidate loop.

• Chain in reverse : de-rate matching, Viterbi decoding, CRC check.
• Blind decoding : repeated for every candidate of the search space.
• RNTI identifies the UE : only a CRC match with its own RNTI is accepted.

Reference

[1] 3GPP TS 36.212 v19.3.0 - clause 5.3.3, Downlink control information, clause 5.1.3.1, Tail biting convolutional coding, and clause 5.1.4.2, Rate matching for convolutionally coded channels

[2] 3GPP TS 36.211 v19.3.0 - clause 6.8, Physical downlink control channel, and Table 6.7-1, Number of OFDM symbols used for PDCCH

[3] 3GPP TS 36.213 v19.4.0 - clause 9.1.1, PDCCH assignment procedure