No PDSCH is received, and no PUSCH is transmitted, until the UE decodes a DCI first. That makes DCI the one structure on the air interface that has to be understood completely. For a long time I read the DCI tables in 38.212 as a lookup and nothing more. That was a mistake. The field lists are the easy part. The harder part is different. It is why there are fifteen formats, how the UE finds the right one, and why the payload sizes are constrained. This page carries both parts. The tables are the lookup, and the sections around them carry the reasoning.

• 5G DCI in a Nutshell
• 5G DCI in Detail
• Why are there so many DCI formats?
• How does the UE know which DCI to decode?
• Format 0_0
• Format 0_1
• Format 1_0
• Format 1_1
• Format 2_0
• Format 2_1
• Format 2_2
• Format 2_3
• Format 2_4
• Format 2_5
• Format 2_6
• Why does the DCI size budget exist?
• Determining the size of DCI
• Reference

5G DCI in a Nutshell

5G DCI in Detail

DCI stands for Downlink Control Information. Simply put, it has several major functionalities as follows :

• Carrying the information to schedule (allocate physical resources) for Downlink Data (PDSCH)
• Carrying the information to schedule (allocate physical resources) for Uplink Data (PUSCH)
• Carrying the information to adjust Uplink Power (PUSCH, PUCCH power) for power control

The main purpose of DCI (Downlink Control Information) is the same as DCI in LTE(I strongly recommend you to read LTE DCI page first if you are not so familiar with what the DCI does). That is, it is a special set of information which schedules downlink data channel (e.g, PDSCH) or uplink data channel (e.g, PUSCH).

Followings are the list of DCI types and its contents defined in 38.212 - 7.3 Downlink control information.

< 38.212 - Table 7.3.1-1: DCI formats >

The Usage column is the specification's own wording, and it is deliberately short. Two formats can carry the same usage line and still be very different, as 0_0 and 0_1 are. The left column links to the field list of each format that this page details.

NOTE : The contents of the table shown here is based on 38.212. This specification is very dry. As any other 3GPP specification, it just describes 'what should be done' and does not describe anything on the background story. To get any further technical background, you need to follow through a lot of TDocs. However, unless you are a firmware or DSP engineer implementing the physical channel, it will be very difficult to keep track of all the TDocs. One trick that I would recommend is to go through several latest TDocs not far away from TS (Technical Specification) because those TDocs usually have the summary of past stories and more detailed design concept. I put several TDocs under Reference section that might help you to get some background stories.

The size of DCI (i.e, the bit length of DCI) is determined by the bit length of each field in it and padding bits (if any). See this for the details

• Determining the size of a DCI

Once a DCI data is constructed, it goes to the channel coding process and transmitted over PDCCH. This process is described in following page.

• PDCCH Transport Process

Why are there so many DCI formats?

Fifteen formats is a large number, and the list above looks arbitrary at first. It is not. The formats fall into three groups, and each group answers a different question. I read the list as fifteen separate things for a long time. Sorting it into the three groups is what made it manageable.

The starting point is that one DCI format cannot serve every case well. A format rich enough to schedule four layer MIMO with carrier aggregation is large. A large DCI needs more coding resource on PDCCH. Therefore it reaches a shorter distance at the same aggregation level. A UE at the cell edge cannot receive a DCI of that size reliably. Neither can a UE that does not yet have a full RRC configuration. So NR splits the same scheduling job into two variants.

The first group is the fallback formats, 0_0 and 1_0. Their field list is fixed and short. Almost nothing in them depends on RRC configuration. Therefore the gNB can send them before the UE is configured. It can also send them during reconfiguration, when the two sides may still disagree about what is configured. That is why DCI 1_0 carries the RAR scheduling, the SIB scheduling and the paging scheduling.

The second group is the non-fallback formats, 0_1 and 1_1. Their field list depends heavily on RRC configuration. Fields appear, disappear, or change width according to what has been configured. That is what makes them large, and it is also what makes them capable. Rel-16 added 0_2 and 1_2 to the same group. Those two allow more of the field widths to be configured, for lower latency and higher reliability.

The third group is the group-common formats, 2_0 to 2_6. They do not schedule data for one UE. Instead they carry information that many UEs read at the same time. Slot format, pre-emption, TPC commands and power saving indications are all in this group. Each format is addressed by its own RNTI. Its payload size is configured by RRC, rather than derived from a field list.

Formats 3_0 and 3_1 are separate from all three groups. They schedule sidelink. The UE that decodes them transmits to another UE, and not to the gNB.

• Fallback formats trade capability for robustness : DCI 0_0 and 1_0 have a short field list that barely depends on RRC configuration. Therefore they still work when the UE has no configuration, and while a configuration is being changed.
• Non-fallback formats trade robustness for capability : DCI 0_1 and 1_1 carry the MIMO, carrier aggregation, CBG and CSI request fields. Their size follows the RRC configuration. Both sides must therefore agree on that configuration before the format can be used.
• Group-common formats are not grants : DCI 2_0 to 2_6 tell a group of UEs something about the cell, or about their own power control. No transport block is scheduled by them.
• The first digit is the direction : 0_x schedules uplink and 1_x schedules downlink. The second digit is the variant, and not the release number.
• Only 0_x and 1_x carry the identifier bit : The 1-bit identifier separates an uplink grant from a downlink assignment. Group-common formats do not carry it, because each of them is identified by its RNTI and its configured size.

How does the UE know which DCI to decode?

The nutshell box above answers this in one line. The UE checks the RNTI that masks the DCI. That line is correct, and it is only half of the answer. The RNTI is how the UE checks a candidate. It is not how the UE finds one. I want to separate those two steps, because almost all of the UE complexity is in the second one.

A DCI carries no explicit UE identifier. Instead the 24-bit CRC of the DCI payload is scrambled with a 16-bit RNTI. The scrambling happens before channel coding, and 38.212 clause 7.3.2 defines it. The UE descrambles a candidate with the RNTI it expects, and then checks the CRC. A CRC that passes means the DCI was addressed to that RNTI. A CRC that fails means the candidate is discarded. In this way a PDCCH transmission carries no addressing overhead at all.

The cost of that design is that the UE has to search. The UE does not know in advance where the DCI is. It does not know how large the DCI is, and it does not know which RNTI it carries. Therefore the UE performs blind decoding. Each configured search space set gives a set of PDCCH candidates and their aggregation levels. For each candidate, the UE attempts a decode for every DCI size it monitors, with every RNTI valid in that search space.

Figure 1. The RNTI never appears in the DCI payload. A candidate can only be confirmed after it has been decoded, and that is the reason blind decoding exists at all.

Three limits keep that search finite. The first is the search space configuration, which fixes where the candidates are. The second is the per-slot limit on PDCCH candidates and on non-overlapping CCEs, given in 38.213 clause 10.1. The third is the DCI size budget, covered in a later section of this page.

The identifier bit does not help the UE find a DCI. It resolves a different problem. DCI 0_0 and DCI 1_0 are deliberately padded to the same size, so a passing CRC alone cannot tell them apart. The first bit of the payload does. A 0 means an uplink grant, and a 1 means a downlink assignment.

• The RNTI is a filter, not an address : The RNTI is not carried in the payload. It is scrambled onto the CRC, so it can only be tested after a candidate has been decoded.
• Blind decoding is the price of zero addressing overhead : Nothing on PDCCH says who a DCI is for, or how long it is. Therefore the UE has to try many candidates instead.
• The search space decides which RNTIs are possible : A Type0 or Type0A common search space uses SI-RNTI. Type1 uses RA-RNTI, MsgB-RNTI and TC-RNTI. Type2 uses P-RNTI. A UE-specific search space uses C-RNTI, CS-RNTI, MCS-C-RNTI and SP-CSI-RNTI. So the UE never tries every RNTI on every candidate.
• The identifier bit separates a pair, not the whole set : It tells DCI 0_0 from DCI 1_0, and DCI 0_1 from DCI 1_1. It is not a format number, and it does not identify which of the four it is.
• A false detection is possible : The CRC is 24 bits, so a single attempt on noise passes with a probability near 2^-24. The number of attempts per slot is large, so the effect is small but not zero.

Format 0_0

This is used for the scheduling of PUSCH in one cell. It is the smallest uplink grant that NR defines, and that is the point of it. Every field below is either fixed in width, or derived from a bandwidth part size that both sides already agree on. Therefore the gNB can send this grant to a UE it has barely configured, and the UE can still read it. It is tempting to treat DCI 0_0 as a stripped-down DCI 0_1. I find the opposite reading more useful. DCI 0_0 is the baseline that always works, and DCI 0_1 is what the gNB may use once the UE is configured.

Frequency domain resource assignment

This is the only field in DCI 0_0 whose width is not fixed. That makes it the field that decides the size of the whole format. Its width follows the size of a bandwidth part, and which bandwidth part applies depends on the search space.

The number of bits(bit length) for this field is determined by following formula

 

The meaning of varies depending on the search space where DCI_0_0 is transmitted.

• When transmitted in common search space,

it indicates the size of the Initial Bandwidth Part

• When transmitted in UE specific search space and meets following criteria

the total number of different DCI sizes monitored per slot <= 4

the total number of different DCI sizes with C-RNTI monitored per slot <= 3

it indicates the size of the Active Bandwidth Part

The value of this field is determined as follows.

Case 1 : PUSCH hopping = True and Resource allocation type 1

• MSB bits are used to indicate the frequency offset
• = 1 if  Frequency-hopping-offsets-set contains two offset values
• = 2 if  Frequency-hopping-offsets-set contains four offset values
• Remaining Bits indicates PUSCH RIV

 

Case 2 : PUSCH hopping = False and Resource allocation type 1

• the whole bits of this field indicates PUSCH RIV

< 38.214 v15.1 - Table 6.1.4.1-1: MCS index table for PUSCH with transform precoding and 64QAM >

This is the table that the 5-bit MCS field indexes into when transform precoding is enabled. The modulation order q is 1 for pi/2-BPSK and 2 for QPSK. Rows 0, 1 and 28 therefore depend on which of the two is configured. Indices 28 to 31 carry no code rate. They are used for retransmissions. The modulation order is then taken from this table, and the transport block size is kept from the initial transmission.

< 38.213 v2.0.0 - Table 7.1.1-1: Mapping of TPC Command Field in DCI format 0_0, DCI format 0_1, or DCI format 2_2, or DCI format 2_3 having CRC parity bits scrambled by TPC-PUSCH-RNTI or TPC-SRS-RNTI, to absolute and accumulated  d_PUSCH,c values >

The 2-bit TPC field carries an index, and not a power value. The same index means two different things, depending on whether the UE is in accumulated or absolute power control mode. In accumulated mode the value is a step added to the current power. In absolute mode it replaces the current offset.

Format 0_1

This is used for the scheduling of PUSCH in one cell. The usage line is the same as DCI 0_0, and the format is not. DCI 0_1 is the configurable uplink grant, and RRC decides almost every field width in the tables below. I used to expect it to be a superset of DCI 0_0. It is not. The frequency hopping flag is always 1 bit in DCI 0_0, and it can be 0 bits here.

< DCI format 0_1 with CRC scrambled by C-RNTI > 

This is the normal case for DCI 0_1, scheduling a PUSCH for one UE. The Bits column often shows a list rather than a single number, because RRC decides the width. A field with 0 in that list disappears completely when the matching feature is not configured.

< DCI format 0_1 with CRC scrambled by CS-RNTI > 

The CS-RNTI variant is not an ordinary grant. It is used with configured grants, and the table below is the form it takes when the DFI flag is set to 1. The DCI then carries HARQ-ACK feedback for configured grant transmissions, and every remaining bit is set to zero.

< 38.212 v17.3.0 - Table 7.3.1.1.1-1: UL/SUL indicator >

This table has two rows because a cell may have two uplink carriers. The field only exists when supplementaryUplink is configured for the cell. Without it the field is 0 bits, and the normal uplink carrier is implied.

< 38.212 v15.3.0 - Table 7.3.1.1.2-1: Bandwidth part indicator  >

The field width follows the number of bandwidth parts configured, so the table gives both the 1-bit and the 2-bit reading. At most four bandwidth parts can be indicated this way. A DCI that changes this value switches the active bandwidth part, so one DCI both switches the BWP and schedules inside the new one.

< Frequency domain resource assignment >

DCI 0_1 supports both resource allocation types, and DCI 0_0 supports only type 1. That is why this field is more complicated here than in the earlier section. When both types are configured, the most significant bit selects between them, and the remaining bits are read accordingly.

The bit length of this field is determined as follows.

The value of this field is determined as follows :

• Resource Allocation Type 0 only : Bitmap determined as described here.
• Resource Allocation Type 1 only : Determined depending on PUSCH Hopping field as follows
• Case 1 : PUSCH hopping = True
• MSB bits are used to indicate the frequency offset
• = 1 if  Frequency-hopping-offsets-set contains two offset values
• = 2 if  Frequency-hopping-offsets-set contains four offset values
• Remaining Bits indicates PUSCH RIV
• Case 2 : PUSCH hopping = False
• the whole bits of this field indicates PUSCH RIV

< 38.214-v15.3.0 Table 6.1.2.2.1-1: Nominal RBG size P >

Resource allocation type 0 is a bitmap over resource block groups, so the group size decides how many bits that bitmap needs. P below is that group size. A larger bandwidth part uses a larger P, which stops the bitmap from growing without limit.

NOTE : Which RBG(Resource Block Group) size to be used is determined by PUSCH-Config.rbg-Size in RRC message from gNB

< SRS resource indicator >

This field identifies one of the SRS resources the UE has been configured with. Its width depends on how many resources are in the set, and on what that set is used for. Codebook and non-codebook usage count the possibilities differently, which is why the two rows differ.

< 38.212-Table 7.3.1.1.2-24: SRS request >

The two bits select which aperiodic SRS resource set to trigger, and not whether SRS is transmitted at all. Value 00 triggers nothing. The other three values select a set by its aperiodicSRS-ResourceTrigger value, so one DCI can address at most three aperiodic sets.

< Precoding information and number of layers >

This field only exists for codebook based uplink transmission. The gNB uses it to tell the UE which TPMI to apply, and how many layers to transmit. Its width is not a single number, because it follows the antenna port count, the transform precoder setting, the maximum rank and the codebook subset.

NOTE : PUSCH-tp indicates PUSCH Transform Precoding. Refer to Transform Precoding section in Waveform Page if you want to know what this is.

NOTE : txConfig, PUSCH-tp, maxRank, codebook Subset are specified by PUSCH-Config in RRC.

<  Antenna ports >

This field selects the DMRS ports for the PUSCH, and with them the number of layers. Its width follows the DMRS configuration rather than the DCI format. 38.212 holds eighteen separate tables for this one field, and the four parameters below decide which of them applies.

NOTE : PUSCH-tp indicates PUSCH Transform Precoding. Refer to Transform Precoding section in Waveform Page if you want to know what this is.

<  PTRS - DMRS Association >

Phase tracking reference signals are transmitted on a subset of the DMRS ports, and this field says which ones. The field is 0 bits in most configurations, including every case where transform precoding is enabled. It becomes 2 bits only in the cases marked Otherwise below, and the number of configured UL PTRS ports then decides which 38.212 table applies.

Format 1_0

This is used for the scheduling of PDSCH in one cell. You will meet DCI 1_0 before any other format, because it is the format that schedules the RAR. The six tables below are one format read with six different RNTIs. The RNTI decides which fields are present. It also decides what the frequency domain resource assignment is measured against. Paging, SIB scheduling and contention resolution all arrive this way.

< DCI format 1_0 with CRC scrambled by C-RNTI >  

This is DCI 1_0 in its ordinary role, scheduling unicast PDSCH for one UE. It is the version a UE monitors in its own search space, beside DCI 1_1. The five variants that follow share the same format, and differ in which fields the RNTI makes meaningful.

NOTE 1 : The meaning of varies depending on the search space where DCI_1_0 is transmitted.

When transmitted in common search space,

it indicates the size of the Initial Bandwidth Part

When transmitted in UE specific search space and meets following criteria

the total number of different DCI sizes monitored per slot <= 4

the total number of different DCI sizes with C-RNTI monitored per slot <= 3

it indicates the size of the Active Bandwidth Part

NOTE 2 : In case of DCI 1_1, this field indicates the index value of dl-DataToUL-ACK, dl-DataToUL-ACK-r16 configured in RRC, but this field in DCI 1_0 refers to the index of pre-defined set {1,2,3,4,5,6,7,8}. This is based on following specification.

38.213-9.2.3

For DCI format 1_0, the PDSCH-to-HARQ_feedback timing indicator field values map to {1, 2, 3, 4, 5, 6, 7, 8}. For a DCI format, other than DCI format 1_0, scheduling a PDSCH reception or a SPS PDSCH release, the PDSCH-to HARQ_feedback timing indicator field values, if present, map to values for a set of number of slots provided by dl- DataToUL-ACK, dl-DataToUL-ACK-r16, or dl-DataToUL-ACKForDCIFormat1_2

< DCI format 1_0 with CRC scrambled by C-RNTI for PDCCH Order>  

This variant schedules nothing. The gNB uses it to order the UE to start a random access procedure. That is why the frequency domain resource assignment is all ones. The UE recognises the variant by that all-ones field, and then reads the preamble index, the SS/PBCH index and the PRACH mask instead.

NOTE 1 : If the value of the "Random Access Preamble index" is not all zeros and if the UE is configured with supplementaryUplink in ServingCellConfig in the cell, this field indicates which UL carrier in the cell to transmit the PRACH according to Table 7.3.1.1.1-1( 0 = Non Supplementary Uplink, 1 = Supplementary Uplink); otherwise, this field is reserved

NOTE 2 : If the value of the "Random Access Preamble index" is not all zeros, this field indicates the SS/PBCH that shall be used to determine the RACH occasion for the PRACH transmission; otherwise, this field is reserved.

NOTE 3 : If the value of the "Random Access Preamble index" is not all zeros, this field indicates the RACH occasion associated with the SS/PBCH indicated by "SS/PBCH index" for the PRACH transmission, according to Clause 5.1.1 of  38.321; otherwise, this field is reserved

NOTE 4 : 12 bits for operation in a cell with shared spectrum channel access; otherwise 10 bits

< DCI format 1_0 with CRC scrambled by RA-RNTI >  

: This is used to schedule RAR (Msg2) in RACH Procedure

At this point the UE has no C-RNTI, so the DCI is addressed with an RA-RNTI derived from the PRACH occasion. There is no HARQ process number and no new data indicator, because Msg2 is not retransmitted through HARQ. The 16 reserved bits are what keeps this variant the same size as the others.

The meaning of varies depending on the search space where DCI_1_0 is transmitted.

When transmitted in common search space in CORESET 0 ,

it indicates the size of the Initial Bandwidth Part

When transmitted in UE specific search space and meets following criteria

the total number of different DCI sizes monitored per slot <= 4

the total number of different DCI sizes with C-RNTI monitored per slot <= 3

it indicates the size of the Active Bandwidth Part

TB Scaling is special parameters affecting the determination of Transport Block Size. This factor is multiplied to the result of the calculated Ninfo value.

< 38.214 - Table 5.1.3.2-2: Scaling factor of Ninfo for P-RNTI, RA-RNTI and MSGB-RNTI >

The scaling factor lowers the transport block size for a given MCS and allocation. It exists because RAR and paging have to reach UEs at the cell edge, and the gNB has no channel knowledge for them. The 2-bit TB scaling field selects one entry below, and that value multiplies Ninfo before the transport block size is looked up.

< DCI format 1_0 with CRC scrambled by TC-RNTI >  

: This is used to schedule Contention Resolution (Msg4) in RACH Procedure

The TC-RNTI is assigned in the RAR, and the UE uses it until contention resolution succeeds. This variant looks almost identical to the C-RNTI version, because Msg4 is an ordinary PDSCH with HARQ feedback. The difference is that the downlink assignment index is reserved here.

The meaning of varies depending on the search space where DCI_1_0 is transmitted.

When transmitted in common search space in CORESET 0 ,

it indicates the size of the Initial Bandwidth Part

When transmitted in UE specific search space and meets following criteria

the total number of different DCI sizes monitored per slot <= 4

the total number of different DCI sizes with C-RNTI monitored per slot <= 3

it indicates the size of the Active Bandwidth Part

< DCI format 1_0 with CRC scrambled by SI-RNTI >  

: This is used to schedule SIB1 and other SIB messages

SI-RNTI is a fixed value, so any UE in the cell can read this DCI. There is no HARQ process number and no new data indicator, because system information is repeated rather than retransmitted. The system information indicator bit separates SIB1 from the other SI messages, and the two use different time domain allocation tables.

[NOTE 1] SIB1 DCI refer to SI-RNTI / Type0Common in 38.214 - Table 5.1.2.1.1-1. As you see in the table, different TimeDomainResourceAllocation table is used depending on SSB/CORESET Multiplexing Pattern as summarized in the following table.

< DCI format 1_0 with CRC scrambled by P-RNTI>  

: This is used to schedule Paging messages

P-RNTI is also a fixed value, and every UE in a paging occasion decodes the same DCI. This variant carries two extra fields at the front of the payload. The short message indicator says whether the DCI schedules a paging message, carries a short message, or does both. A short message needs no PDSCH at all, so the UE can act on it without decoding anything further.

< 38.212 - Table 7.3.1.2.1-1: Short Message indicator >

The two bits below decide how the rest of the paging DCI is read. Value 01 means the short message field is reserved. Value 10 means the scheduling fields are reserved. Value 11 means both are present, and both are valid.

< 38.331 - Table 6.5-1: Short messages >

A short message is an 8-bit field, and only two of those bits are defined. Bit 1 tells the UE that system information has changed and has to be acquired again. Bit 2 tells it that an ETWS or CMAS notification is present. The UE ignores the remaining bits.

Format 1_1

This is used for the scheduling of PDSCH in one cell. DCI 1_1 carries what DCI 1_0 leaves out. That includes the second transport block, the antenna ports and layers, CBG retransmission, the TCI field and rate matching. It is also the largest DCI a UE normally monitors. Therefore it is the format that the size budget constrains first.

< Antenna port(s) and number of layers >

This is the downlink counterpart of the antenna ports field in DCI 0_1. The field selects the DMRS ports for the PDSCH, and with them the number of layers. Its width is 4, 5 or 6 bits, and the two DMRS parameters below decide which.

Format 2_0

DCI 2_0 is the first of the group-common formats, and it schedules nothing. It tells a group of UEs how the coming slots are divided between downlink, uplink and flexible symbols. The four tables below are not four formats. They are four field groups, and the gNB includes each group only if the matching RRC list is configured.

This is used for notifying following information to UE. This DCI is scrambled by SFI-RNTI

• Slot format
• COT(Channel Occupancy Time) duration
• Available RB set
• Search space set group switching

If the higher layer parameter slotFormatCombToAddModList is configured

Field (Item)	Bits	Reference
Slot format indicator	Variable	Bit size is determined by RRC message here

Slot format indicator : a Bit string indicating Slot format indicator 1, Slot format indicator 2, , Slot format indicator N

If the higher layer parameter availableRB-SetsToAddModList is configured

Field (Item)	Bits	Reference
Available RB set Indicator	Variable	Bit size is determined by RRC message here

Available RB set Indicator : a Bit string indicating Available RB set Indicator 1, Available RB set Indicator 2, , Available RB set Indicator N

If the higher layer parameter co-DurationsPerCellToAddModList is configured

Field (Item)	Bits	Reference
COT duration indicator	Variable	Bit size is determined by RRC message here

COT duration indicator : a Bit string indicating COT duration indicator 1, COT duration indicator 2, , COT duration indicator N

If the higher layer parameter switchTriggerToAddModList is configured

Field (Item)	Bits	Reference
Search space set group switching flag	Variable	Bit size is determined by RRC message here

Search space set group switching flag : a Bit string indicating Search space set group switching flag1, Search space set group switching flag 2, , Search space set group switching flag N. (Details are in 38.213 - 11.1.1)

NOTE : Not every UE would support this DCI. That is, supporting DCI 2_0 decoding depends on UE capability. UE Capability Information related to DCI 2_0 decoding are listed below.

Phy-ParametersXDD-Diff ::= SEQUENCE {

    dynamicSFI                                   ENUMERATED {supported} OPTIONAL,

    ...

}

 

Phy-ParametersFRX-Diff ::= SEQUENCE {

    dynamicSFI                                   ENUMERATED {supported} OPTIONAL,

    ...

}

 

SharedSpectrumChAccessParamsPerBand-r16 ::= SEQUENCE {

    ...

    dci-AvailableRB-Set-r16                  ENUMERATED {supported} OPTIONAL,

    dci-ChOccupancyDuration-r16          ENUMERATED {supported} OPTIONAL,

    ...

}

Format 2_1

This is used for notifying the PRB(s) and OFDM symbol(s) where UE may assume no transmission is intended for the UE. This DCI is scrambled by INT-RNTI. A gNB sometimes has to reclaim resources it has already granted, and low latency traffic for another UE is the usual reason. The UE that lost those resources has already stored soft bits for them. DCI 2_1 tells that UE which resources to exclude, so the next HARQ combining is not corrupted by them.

The size of DCI format 2_1 is configurable by higher layers up to 126 bits and each Pre-emption indication is 14 bits(Details are in 38.213 - 11.2)

Format 2_2

This is used for the transmission of TPC commands for PUCCH, PUSCH. This DCI is scrambled by TPC-PUSCH-RNTI or TPC-PUCCH-RNTI. A TPC command is two bits, so a dedicated grant for one command would waste an entire PDCCH. DCI 2_2 avoids that. Many commands share a single transmission, and RRC tells each UE in advance which bit position belongs to it. I searched for a per-UE power control DCI for a long time before I understood that there is none.

Following fields are defined for each block

Format 2_3

This is used for the transmission of a group of TPC commands for SRS transmissions by one or more UEs. Along with a TPC command, a SRS request may also be transmitted. DCI 2_3 does for SRS what DCI 2_2 does for PUSCH and PUCCH. It exists because SRS power control is not always tied to PUSCH power control. A UE with no PUSCH and no PUCCH on a carrier still transmits SRS there, and that SRS still needs a power command.

Following fields are defined for each block

If the UE is configured with higher layer parameter srs-TPC-PDCCH-Group = typeA for an UL without PUCCH and

PUSCH or an UL on which the SRS power control is not tied with PUSCH power control

If the UE is configured with higher layer parameter srs-TPC-PDCCH-Group = typeB for an UL without PUCCH and

PUSCH or an UL on which the SRS power control is not tied with PUSCH power control

Format 2_4

This DCI is used for notifying the PRB(s) and OFDM symbol(s) where UE cancels the corresponding UL transmission from the UE (Details are in 38.213-11.2A). This is scrambled by ci-RNTI. DCI 2_1 is the downlink form of the same idea, and this is the uplink form. The difference matters. Downlink pre-emption is reported after the fact, because the data has already been transmitted. Uplink cancellation has to arrive before the UE transmits, so its timing requirement is far tighter.

Format 2_5

This DCI is used for notifying the availability of soft resources (Details in 38.473-9.3.1). This is scrambled by AI-RNTI. This format only appears in an IAB deployment. Its receiver is the mobile termination of an IAB node, and not an ordinary UE. Soft resources are the resources that the parent node has neither granted nor forbidden. I have never seen DCI 2_5 in a handset log, and that is expected.

Format 2_6

This DCI is used for notifying the power saving information outside DRX Active Time for one or more UEs. This is scrambled by PS-RNTI. The word outside is the important one. DCI 2_6 is monitored before the DRX on-duration starts, and not during it. If the wake-up indication is 0, the UE skips the whole on-duration and stays asleep. That is the saving, and it only works because this format is small enough to monitor cheaply.

Structure of DCI format 2_6 is as follows :

block number 1, block number 2,, block number N

Structure of each block is as follows :

Why does the DCI size budget exist?

The numbers 4 and 3 appear several times on this page, beside the frequency domain resource assignment notes. They are quoted there as a rule, with no reason attached. The reason is blind decoding. I treated those two numbers as a specification quirk for years. They are the whole reason the fallback formats are padded.

Every distinct DCI size the UE monitors multiplies the number of decode attempts. For one PDCCH candidate, the UE attempts one decode per size it is configured to monitor. Two sizes therefore double the work on the same candidate set. So the number of sizes has to be bounded, and both sides have to know the bound.

38.213 clause 10.1 sets that bound for one serving cell in one slot. The UE monitors at most 4 different DCI sizes. At most 3 of those 4 may have a CRC scrambled by C-RNTI. Everything the gNB configures has to fit inside those two numbers.

Figure 2. The budget is on distinct sizes, not on the number of DCIs. Aligning DCI 0_0 with DCI 1_0 is what keeps the non-fallback formats inside the budget.

The fallback formats are what makes the budget workable. DCI 0_0 and DCI 1_0 are aligned to one common size. Together they consume one size out of the four, and not two. 38.212 clause 7.3.1.0 defines the alignment. If DCI 0_0 is smaller than DCI 1_0, zero padding bits are appended to DCI 0_0. If DCI 0_0 is larger, the frequency domain resource assignment field of DCI 0_0 is truncated from its most significant bits. The procedure runs separately for the common search space and for the UE-specific search space.

The budget also changes what a field means. In a UE-specific search space, the frequency domain resource assignment of DCI 0_0 and DCI 1_0 is sized from the active bandwidth part. That only holds while both counts stay inside the budget. If the number of sizes exceeds 4, or the number of C-RNTI sizes exceeds 3, the field is sized from the initial bandwidth part instead. This is the condition written beside the frequency domain resource assignment notes earlier on this page.

Group-common formats stay outside that derivation. Their payload size is not computed from a field list. For DCI 2_0 and DCI 2_1 the size is configured directly by RRC, through dci-PayloadSize. Therefore the UE knows the size before it decodes anything, and the size does not move with the bandwidth part.

• The budget is 4 sizes, and 3 of them with C-RNTI : The limit is per serving cell and per slot, from 38.213 clause 10.1. It counts distinct sizes, and not the number of DCIs the UE may receive.
• Alignment saves one entry : DCI 0_0 and DCI 1_0 share a size. Therefore the pair costs one entry in the budget instead of two.
• Padding goes on DCI 0_0, and truncation goes on its FDRA field : The alignment is never done by changing DCI 1_0. Zero bits are appended to DCI 0_0, or its frequency domain resource assignment is truncated from the most significant bits.
• Exceeding the budget changes a field, not only a count : Once the budget is exceeded, the frequency domain resource assignment of DCI 0_0 and 1_0 changes its baseline. In a UE-specific search space it is then sized from the initial bandwidth part. The same DCI means something different.
• Group-common sizes are configured, not derived : For DCI 2_0 and 2_1 the payload size comes from RRC. So a group-common format costs a fixed entry in the budget, which the gNB chooses.

Determining the size of DCI

The section above explains why DCI sizes are constrained. This section is the arithmetic behind a single size. The order of the steps matters, because one field width can depend on a value that is itself configured.

In 5G NR (New Radio), the DCI (Downlink Control Information) is a critical component of the Physical Downlink Control Channel (PDCCH). It carries scheduling information, resource allocation details, and other control data necessary for the UE (User Equipment) to communicate with the network. The size (bit length) of the DCI is not fixed and is determined dynamically based on several factors, including the DCI format, the configuration of the system, and the use case.

In short, The size of the DCI in 5G NR is determined by:

• The DCI format.
• The fields included.
• The BWP size and resource allocation type.
• RRC-configured parameters.
• Padding for size alignment.

The exact size is calculated by the network and signaled to the UE for efficient PDCCH decoding.

Here's a detailed explanation:

DCI Formats

The format is the first term in the calculation, because it fixes which fields exist at all.

The size of the DCI depends on the specific DCI format being used. 5G NR defines several DCI formats, each tailored for different purposes:

• DCI Format 0_0: Uplink scheduling (compact, used in fallback scenarios).
• DCI Format 0_1: Uplink scheduling (non-fallback, more flexible and detailed).
• DCI Format 1_0: Downlink scheduling (compact, fallback).
• DCI Format 1_1: Downlink scheduling (non-fallback, more detailed).
• DCI Format 2_x: Group-common DCI (e.g., 2_0 for slot format indication, 2_1 for preemption indication, etc.).

Each format has a baseline set of fields, and the bit length varies depending on the complexity and number of parameters included.

Fields in DCI

Once the format is known, the size is a sum. Some terms in that sum are constants, and the rest are not.

The total bit length of a DCI is the sum of the bits required for all fields included in a given format. Common fields include:

• Frequency domain resource assignment: Depends on the bandwidth part (BWP) size and resource allocation type.
• Time domain resource assignment: Typically 4 bits.
• Modulation and Coding Scheme (MCS): Usually 5 bits per transport block.
• HARQ process number: 4 bits.
• New Data Indicator (NDI): 1 bit per transport block.
• Redundancy Version (RV): 2 bits.
• Carrier indicator: 0 or 3 bits (for cross-carrier scheduling).
• BWP indicator: 0–2 bits, depending on the number of configured BWPs.

Bandwidth Part (BWP) Dependency

One field dominates the variable part of that sum. It is also the only one that changes when the carrier bandwidth changes.

The size of the frequency domain resource assignment field is a major contributor to DCI size and is calculated based on the active Bandwidth Part (BWP):

• Resource Allocation Type 0: Uses a bitmap for resource block groups (RBGs). The number of bits is determined by:
  Formula: N_RBG = ⌈ (N^size_BWP + (N^start_BWP mod P)) / P ⌉, where N^size_BWP is the number of PRBs in the BWP, N^start_BWP is the first PRB of the BWP, and P is the RBG size.
• Resource Allocation Type 1: Uses a contiguous resource allocation. The number of bits is:
  Formula: ⌈ log₂(N^size_BWP · (N^size_BWP + 1) / 2) ⌉.

The larger the BWP, the more bits are needed.

Payload Size Alignment

You cannot compute the transmitted size from the field list alone. Alignment is applied after the sum, and it can add bits or remove them.

To ensure efficient decoding, the DCI sizes for certain formats are aligned or padded:

• Fallback DCI (0_0 and 1_0): Sizes are aligned within a search space by padding the smaller DCI with zeros.
• Non-fallback DCI (0_1 and 1_1): More flexible, sizes depend on RRC configuration.

Example >

As written in TS 38.212 section 7.3, DCI format 0_0 in common search space is padded with zeros so that it matches the size of DCI format 1_0. So if the DCI format 0_0 carries only 33 bits of contents, it gets padded to get transmitted with the size of 41 (the size of format 1_0).

RRC Configuration

Several of the widths above are not properties of the format. They are properties of the configuration, and they change when the configuration changes.

The network configures parameters via RRC signaling, affecting DCI size:

• Number of MIMO layers: Impacts precoding information.
• Cross-carrier scheduling: Adds a carrier indicator field.
• Dynamic HARQ-ACK codebook: Adds feedback timing fields.

Search Space and CORESET

The last input is where the DCI is transmitted. The same format can have one size in a common search space and a different size in a UE-specific one.

The DCI size is influenced by the search space and CORESET configuration:

• In common search space: Simpler formats (e.g., 1_0) with smaller sizes.
• In UE-specific search space: Larger formats (e.g., 1_1).

Reference

38.212 defines every field list on this page. The TDocs below it are the design discussion behind those field lists, from the RAN1 meetings where the formats were settled. The specification does not carry that reasoning. That is the reason the TDocs are listed here.

[1] 3GPP TS 38.212 NR;Multiplexing and channel coding   

[2] 3GPP TSG RAN WG1 Meeting #92  : R1-1802117 : Discussion on DCI contents

[3] 3GPP TSG-RAN WG1 #92 : R1-1802905 : Remaining issues of the DCI contents and formats  

[4] 3GPP TSG RAN WG1 Meeting #92 : R1-1801976 : DCI Contents and Formats

[5] 3GPP TSG RAN WG1 Meeting #92 : R1-1802097 : Remaining issues on MIMO related DCI design

[6] 3GPP TSG RAN WG1 Meeting #92 : R1-1802482 : DCI contents and formats

[7] 3GPP TSG RAN WG1 Meeting #92 : R1-1802597 : Remaining issues in DCI contents and formats  

[8] 3GPP TSG RAN WG1 Meeting #92 : R1-1802209 : Remaining issues on DCI contents and formats

[9] 3GPP TSG RAN WG1 Meeting #92 : R1-1801730 : Open issues on DCI contents and formats

[10] 3GPP TSG RAN WG1 Meeting #92 : R1-1801624 : Remaining issues on DCI content

[11] 3GPP TSG RAN WG1#100bis-e R1-e-Meeting, April 20th 30th, 2020 : Email discussion/approval on special states/indications in available RB set indication and COT duration indication/determination (NR-U DL Signals and Channels)

[12] 3GPP TS 38.213 NR;Physical layer procedures for control   

[13] 3GPP TS 38.214 NR;Physical layer procedures for data