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 0_2
• Format 0_3
• Format 1_0
• Format 1_1
• Format 1_2
• Format 1_3
• Format 2_0
• Format 2_1
• Format 2_2
• Format 2_3
• Format 2_4
• Format 2_5
• Format 2_6
• Format 2_7
• Format 3_0
• Format 3_1
• Format 3_2
• Format 4_0
• Format 4_1
• Format 4_2
• Why does the DCI size budget exist?
• Determining the size of DCI
• Reference

5G DCI in a Nutshell

A DCI is a short control message. The difficulty is that the UE has to decode one before it knows what it is. Nothing in the payload names the format. The UE has to work that out from where the message was found, how long it was, and which identity unscrambled the CRC. The box below states the essentials, and the sections after it take the formats one at a time.

5G DCI in Detail

A handful of jobs are spread across a dozen formats, because each format carries only what its job needs. The sections that follow cover the formats one at a time, and the two sections at the end explain why the trimming matters.

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 0_2

DCI format 0_2 is used for the scheduling of PUSCH in one cell, which is what DCI 0_1 also does. It is the uplink twin of DCI 1_2, and it arrived in the same Release 16 work. The CRC is scrambled by C-RNTI, and also by CS-RNTI or SP-CSI-RNTI in the cases those identities cover.

The design idea is the one described in the Format 1_2 section above. Field widths are not derived from the bandwidth part and the feature set. They are configured, and many of them can be configured to zero bits. A grant that carries less is shorter, and a shorter grant is easier to receive at the edge of a cell.

The parameters that do the sizing all end in DCI-0-2, and they sit mostly in PUSCH-Config. The table below lists the ones that change a field width in this format.

< DCI Format 0_2 fields whose width RRC sets >

• It schedules the same channel as DCI 0_1 : 38.212 defines both as the scheduling of PUSCH in one cell, so the difference is the encoding.
• The suffix DCI-0-2 marks the family : harq-ProcessNumberSizeDCI-0-2, numberOfBitsForRV-DCI-0-2 and antennaPortsFieldPresenceDCI-0-2 are examples, and there are many more.
• Several fields can vanish : antenna ports, DMRS sequence initialization and the downlink assignment index are 0 bit unless their parameter is configured.
• Frequency hopping is configured separately : frequencyHoppingDCI-0-2 and frequencyHoppingOffsetListsDCI-0-2 give this format its own hopping setup.
• It is the uplink half of a pair : reading it beside the Format 1_2 section above shows the same idea applied in the two directions.

Format 0_3

DCI format 0_3 is used for the scheduling of one or multiple PUSCHs in one cell. It also covers multiple PUSCHs in multiple cells, with one or multiple PUSCHs per cell. That last part is what makes it new. One grant can reach more than one carrier. The CRC is scrambled by C-RNTI.

Release 18 added this format for multi-cell scheduling. Carrier aggregation before it needed one PDCCH per scheduled cell, so a UE aggregating several carriers spent several decodes and the network spent several control resources. A single DCI that names a set of cells removes that cost.

The configuration lives in PUSCH-ConfigDCI-0-3-r18, reached through pusch-ConfigDCI-0-3-r18 in PUSCH-Config. It repeats the pattern DCI 0_2 established, with its own copy of the fields that decide widths.

• One grant, several cells : 38.212 defines the format as scheduling multiple PUSCHs in multiple cells, with one or multiple PUSCHs per cell.
• It has its own configuration structure : PUSCH-ConfigDCI-0-3-r18 carries resourceAllocationDCI-0-3-r18, rbg-SizeDCI-0-3-r18, numberOfBitsForRV-DCI-0-3-r18 and harq-ProcessNumberSizeDCI-0-3-r18.
• A third RBG configuration appears here : rbg-SizeDCI-0-3-r18 is ENUMERATED {config2, config3}, and config3 does not exist in the original nominal RBG size table.
• The granularity parameter returns : resourceAllocationType1GranularityDCI-0-3-r18 makes the type 1 RIV count resource block groups rather than resource blocks.
• It is the uplink counterpart of DCI 1_3 : the two were added together, and they solve the same problem in the two directions.

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 1_2

DCI format 1_2 is used for the scheduling of PDSCH in one cell, which is the same job DCI 1_1 does. What separates them is not the job but the size. DCI 1_2 arrived in Release 16 for traffic that needs a short, reliable grant. It does that by letting RRC set the width of almost every field.

DCI 1_1 derives most of its widths from the configuration of the bandwidth part and the features in use. A field exists because the feature exists, and its width follows from the numbers around it. DCI 1_2 breaks that link. Many of its fields can be configured down to zero bits. A network that does not need a field does not carry it.

The table below lists the fields whose width DCI 1_2 makes configurable, together with the parameter that sets each one. Every field here has a matching parameter ending in DCI-1-2, and that suffix marks this format.

< DCI Format 1_2 fields and the parameters that size them >

Two consequences follow, and both matter when a log is read rather than when a cell is planned. A DCI 1_2 payload cannot be decoded from the format alone, because the same format is a different length in two cells. The size also counts against the budget in the section further down. A DCI 1_2 that happens to match another format costs nothing extra.

• The format schedules the same thing as DCI 1_1 : 38.212 defines it as the scheduling of PDSCH in one cell. The difference is in the encoding, not in what is scheduled.
• Almost every width is an RRC parameter : the suffix DCI-1-2 appears on more than twenty parameters. Each one sizes a field in this format.
• Fields can be configured away entirely : antenna ports, TCI, SRS request, DMRS sequence initialization and downlink assignment index are all 0 bit unless their parameter is present.
• Redundancy version can be dropped : numberOfBitsForRV-DCI-1-2 allows 0, 1 or 2 bits. A cell that always sends RV 0 need not carry the field.
• Two cells can disagree on the length : the same format is a different number of bits under two configurations. A decoder needs the RRC configuration, not just the format number.
• It shares the size budget : a DCI 1_2 size counts toward the limit described further down. Aligning it with a size already monitored costs nothing.

Format 1_3

DCI format 1_3 is used for the scheduling of one or multiple PDSCHs in one cell. It also covers multiple PDSCHs in multiple cells, with one or multiple PDSCHs per cell. It is the downlink half of the Release 18 multi-cell pair. The CRC is scrambled by C-RNTI.

The problem it solves is the count of decodes rather than the size of any one grant. A UE aggregating four carriers had to find four PDCCHs to be scheduled on all four. One DCI that covers a set of cells turns that into a single search, which matters most where the control channel is the scarce resource.

PDSCH-ConfigDCI-1-3-r18 holds the configuration, and it is reached through pdsch-ConfigDCI-1-3-r18 in PDSCH-Config. Several parameters elsewhere carry a DCI-1-3 copy for the same reason.

• One grant can cover a set of cells : the format is defined for multiple PDSCHs in multiple cells. That is what separates it from DCI 1_1.
• Its configuration mirrors DCI 1_2 : PDSCH-ConfigDCI-1-3-r18 carries its own resourceAllocation, rbg-Size and granularity parameters, all with the DCI-1-3-r18 suffix.
• rbg-Size reaches config3 here : rbg-SizeDCI-1-3-r18 is ENUMERATED {config1, config2, config3, spare1}, which is a wider choice than PDSCH-Config offers.
• Rate matching follows the same pattern : rateMatchListDCI-1-3 carries a rate matching indicator index per scheduled cell, because one DCI now covers several.
• Release 19 extended the allocation list : pdsch-TimeDomainAllocationListForMultiPDSCH-DCI-1-3-r19 gives this format its own multi-PDSCH allocation list.

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.

Following is based on 38.331 v19.3.0 (Release 19)

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)

The message is addressed the same way the other group-common formats are. RRC gives each serving cell a position inside a payload of a configured length, and a UE reads only the bits at its own position.

• One structure configures the whole feature : DownlinkPreemption carries int-RNTI, timeFrequencySet, dci-PayloadSize and a list of INT-ConfigurationPerServingCell.
• The granularity is chosen, not fixed : timeFrequencySet is ENUMERATED {set0, set1}, and it decides how the indicated region is split between time and frequency.
• Each serving cell has its own position in the payload : INT-ConfigurationPerServingCell carries positionInDCI, so one message can cover several cells at once.
• It is enabled per bandwidth part : downlinkPreemption is a SetupRelease inside PDCCH-Config, so the feature follows the bandwidth part configuration.

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

The addressing is what makes this format work. RRC gives each UE an index into the message, and the UE reads the two bits at that index and ignores everything else. The index is configured separately for each thing being powered.

• Each UE is told where to look : PUCCH-TPC-CommandConfig carries tpc-IndexPCell and tpc-IndexPUCCH-SCell, both INTEGER (1..15), and PUSCH-TPC-CommandConfig carries tpc-Index and tpc-IndexSUL.
• The two directions use different identities : the same format is scrambled by TPC-PUCCH-RNTI when it powers PUCCH and by TPC-PUSCH-RNTI when it powers PUSCH.
• An uplink can be pointed at another cell : PUSCH-TPC-CommandConfig carries targetCell. The command can then apply to a serving cell other than the one that sent it.
• Release 17 added indices for the second PUCCH group : tpc-IndexPUCCH-sSCell-r17 and tpc-IndexPUCCH-sScellSecondaryPUCCHgroup-r17 extend the same scheme.

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

This format is addressed by a bit offset rather than by a block index. That is the one structural difference from the TPC format above it. RRC gives the UE the first bit of its own field and the kind of field it is.

• The offset is configured, not derived : SRS-TPC-CommandConfig carries startingBitOfFormat2-3 as INTEGER (1..31), which is the first bit of this UE field inside the message.
• The field can be one of two shapes : fieldTypeFormat2-3 is INTEGER (0..1). It selects whether the field carries a TPC command alone, or one together with an SRS request.
• A supplementary uplink gets its own offset : startingBitOfFormat2-3SUL points at a separate field, so the two uplinks are powered independently.
• Release 19 widened the range : startingBitOfFormat2-3-r19 is INTEGER (1..45), which lets the message address more UE fields than the original 31 bits allowed.

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.

The format is the uplink counterpart of the pre-emption indication above. One transmission has to stop so that another can proceed. Telling the interrupted UE afterwards costs less than scheduling around a case that rarely happens.

What arrives is not a grant. It is a region in time and frequency, and any uplink the UE had already been granted inside that region is dropped rather than rescheduled. The configuration decides how large the message is and which slice of it belongs to which cell.

• One RRC structure carries the whole setup : UplinkCancellation-r16 holds ci-RNTI-r16, dci-PayloadSizeForCI-r16 and a list of CI-ConfigurationPerServingCell-r16.
• The payload size is configured, not implied : dci-PayloadSizeForCI-r16 fixes the length of the message. The UE knows how many bits to expect before it decodes one.
• It is enabled per bandwidth part : uplinkCancellation-r16 is a SetupRelease inside PDCCH-Config. The feature can be present on one bandwidth part and absent on another.
• The reference is 38.213 clause 11.2A : that clause is where the cancelled region becomes actual symbols.

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.

This format belongs to an IAB deployment rather than to a UE. The receiver is the mobile termination of a relay node. It is told which of its resources the parent node is leaving available.

Soft resources are the third category alongside hard and unavailable. A soft resource is usable only when the parent says so, and this format is how the parent says it. The availability is signalled as a combination index rather than as a resource list.

• The configuration lists combinations, not resources : AvailabilityIndicator-r16 carries availableCombToAddModList-r16, a list of AvailabilityCombinationsPerCell-r16, so one codepoint names a whole pattern.
• Each cell is given its position : positionInDCI-AI-r16 places one cell entry inside the payload, as the other group-common formats place a UE.
• The payload size is configured : dci-PayloadSizeAI-r16 is INTEGER (1..maxAI-DCI-PayloadSize-r16), so the length is known before decoding.
• The identity is its own RNTI : ai-RNTI-r16 scrambles the CRC, which keeps this format apart from every other group-common one.

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 :

The configuration behind this format is worth reading beside the message, because it fixes both when the UE looks and what it finds. The offset decides when, and the position and size decide which bits belong to this UE.

• One structure holds the whole arrangement : DCP-Config-r16 carries ps-RNTI-r16, ps-Offset-r16, sizeDCI-2-6-r16, ps-PositionDCI-2-6-r16 and three enabling flags.
• The offset places the monitoring occasion : ps-Offset-r16 is INTEGER (1..120). It puts the occasion ahead of the DRX ON duration, so the UE can act before waking.
• Size and position are separate parameters : sizeDCI-2-6-r16 gives the length of the whole message and ps-PositionDCI-2-6-r16 gives this UE its starting bit.
• The wake-up bit is optional : ps-WakeUp-r16 is ENUMERATED {true} and Need S, so a UE can be configured to read only the reporting flags.
• It can also suppress reporting : ps-TransmitPeriodicL1-RSRP-r16 and ps-TransmitOtherPeriodicCSI-r16 decide whether periodic reports continue outside Active Time.

Format 2_7

DCI format 2_7 is used for notifying the paging early indication and TRS availability indication for one or more UEs. It is the last of the group-common formats, and it was added in Release 17. The CRC is scrambled by PEI-RNTI.

Paging costs a UE more than the paging message itself. The UE has to wake, receive the paging occasion and decode it, only to find in most cases that the page was not for it. An early indication is a much smaller message sent ahead of the occasion. A UE that sees no indication for its subgroup returns to sleep without decoding anything else.

The configuration is broadcast rather than dedicated. PEI-Config-r17 arrives in DownlinkConfigCommonSIB, so a UE in idle mode can read it before it has any dedicated configuration at all.

• It is read before the paging occasion, not instead of it : pei-FrameOffset-r17 places the indication ahead of the occasion. The UE learns early whether waking further is worthwhile.
• The payload size is configured, not derived : payloadSizeDCI-2-7-r17 is INTEGER (1..maxDCI-2-7-Size-r17), and 38.212 points at it directly for the size of this format.
• UEs are addressed in subgroups : subgroupConfig-r17 divides the UEs sharing a paging occasion, so one indication does not wake all of them.
• One indication can cover several occasions : po-NumPerPEI-r17 is ENUMERATED {po1, po2, po4, po8}, which is how many paging occasions one message covers.
• It also carries TRS availability : the same format tells the UE whether a tracking reference signal is available, which saves a separate search.

Format 3_0

DCI format 3_0 is used for scheduling of NR PSCCH and NR PSSCH in one cell. It also covers NR PSCCH, NR PSSCH and NR SL PRS for a shared SL PRS resource pool. It schedules sidelink channels, and that sets the whole 3_x group apart.

Everything above this point schedules a link between the network and one UE. A sidelink grant does something else. The gNB tells one UE what resources to use when it transmits directly to another UE. The receiving UE is not addressed by this DCI at all.

The CRC is scrambled by SL-RNTI, or by SL-CS-RNTI when the grant activates or releases a configured sidelink grant. Release 16 introduced the format together with the NR sidelink work, configured through sl-ConfigDedicatedNR-r16.

• It schedules a link the network does not carry : the resources named in the grant are used between two UEs, not between UE and gNB.
• Two identities separate the two modes : SL-RNTI marks a dynamic grant and SL-CS-RNTI marks the activation or release of a configured one.
• Release 18 widened what it can schedule : the format now also covers NR SL PRS for a shared resource pool, which is sidelink positioning.
• It is configured as part of the sidelink setup : sl-ConfigDedicatedNR-r16 arrives in RRCReconfiguration, so the format only applies to a UE set up for sidelink.
• It counts against the size budget : 38.212 states the rule for DCI formats 3_0, 3_1 and 3_2 explicitly. The section further down explains why that matters.

Format 3_1

DCI format 3_1 is used for scheduling of LTE PSCCH and LTE PSSCH in one cell. The channels are LTE sidelink channels rather than NR ones, and that single word is the whole difference from the format above it.

The format exists because NR and LTE sidelink coexisted. A UE could be connected to a 5G network and still use the LTE sidelink for a service defined there, and something had to schedule it. An NR gNB issues this format to grant LTE sidelink resources.

The CRC is scrambled by the SL Semi-Persistent Scheduling V-RNTI. That is an LTE identity, not one of the NR ones used elsewhere on this page. That is consistent with what the format schedules.

• It grants LTE resources from an NR network : the scheduling entity is the NR gNB, and the channels scheduled are the LTE PSCCH and PSSCH.
• The identity comes from LTE as well : the CRC is scrambled by the SL Semi-Persistent Scheduling V-RNTI rather than by an NR sidelink RNTI.
• It exists for coexistence, not for new capability : the format adds no sidelink feature. It lets an NR network schedule a sidelink that LTE already defined.
• It shares the 3_x budget rule : 38.212 groups it with formats 3_0 and 3_2 when it states how sidelink formats count toward the monitored sizes.

Format 3_2

DCI format 3_2 is used for scheduling of NR PSCCH and NR SL PRS for a dedicated SL PRS resource pool in one cell. It is the newest of the sidelink formats, and it schedules positioning rather than data.

Sidelink positioning measures the distance between two UEs directly, without either of them reaching the network for the measurement. The reference signal used for that is the SL PRS, and a dedicated resource pool is one reserved for it. Format 3_0 can schedule an SL PRS in a shared pool, and this format is the dedicated case.

The CRC is scrambled by SL-PRS-RNTI, or by SL-PRS-CS-RNTI for a configured grant. Both identities exist only for this purpose.

• It schedules positioning, not data : the format covers NR PSCCH and NR SL PRS, and it does not schedule PSSCH.
• Dedicated is the word that separates it from 3_0 : format 3_0 covers an SL PRS in a shared pool. This format covers a dedicated one.
• It has its own pair of identities : SL-PRS-RNTI marks a dynamic grant and SL-PRS-CS-RNTI marks a configured one, matching the pattern format 3_0 uses.
• It belongs to the Release 18 positioning work : the sidelink positioning resource structures carry the -r18 suffix, as in SL-PosTxResourceReq-r18.

Format 4_0

DCI format 4_0 is used for the scheduling of PDSCH for broadcast or for multicast in RRC_INACTIVE state in DL cell. It is the first of three formats added in Release 17 for multicast and broadcast services. The 4_x group is the newest on this page.

A broadcast transmission has no single recipient, so the grant cannot be addressed to one UE. It is addressed to a group instead, and every UE in that group decodes the same DCI and receives the same PDSCH. The identity in the CRC defines the group.

The CRC is scrambled by MCCH-RNTI, or by a G-RNTI for broadcast configured by MBS-SessionInfo. The RRC_INACTIVE case in the definition is what lets a UE receive multicast without moving to connected mode.

• The grant is addressed to a group : MCCH-RNTI or a broadcast G-RNTI scrambles the CRC, so every UE in the group reads one DCI.
• It reaches UEs that are not connected : the definition names RRC_INACTIVE, so a UE can receive multicast without a dedicated configuration.
• It always uses resource allocation type 1 : 38.214 lists formats 1_0, 4_0 and 4_1 together for that rule.
• Its configuration comes from the MBS structures : the broadcast case is configured by MBS-SessionInfo, and the multicast PDSCH by pdsch-ConfigMulticast-r17.

Format 4_1

DCI format 4_1 is used for the scheduling of PDSCH for multicast in DL cell. Multicast differs from broadcast in that the group is known and its members are in connected mode, so feedback becomes possible.

That difference is the reason two formats exist rather than one. A broadcast has no return path, and the network sends it whether or not anyone received it. A multicast group can acknowledge, and a network that receives acknowledgements can retransmit. The formats differ in what they have to carry to support that.

The CRC is scrambled by a G-RNTI for multicast, or by a G-CS-RNTI configured by MBS-RNTI-SpecificConfig for a configured grant.

• The group is a configured one : a G-RNTI identifies the multicast group, and MBS-RNTI-SpecificConfig is where the group specific settings live.
• A configured grant version exists : G-CS-RNTI covers the semi-persistent case, in the same way CS-RNTI does for unicast.
• It also uses resource allocation type 1 : 38.214 names format 4_1 alongside 1_0 and 4_0 when it fixes the downlink resource allocation type.
• It shares pdsch-ConfigMulticast with format 4_2 : the same PDSCH configuration serves both multicast formats, including its own rateMatchPatternGroup pair.
• A UE can belong to several groups at once : MAC-CellGroupConfig carries g-RNTI-ConfigToAddModList-r17, a list of up to maxG-RNTI-r17 entries of MBS-RNTI-SpecificConfig-r17.
• The PDSCH sits in a common frequency resource : pdsch-ConfigMulticast-r17 is reached through CFR-ConfigMulticast-r17. Multicast arrives on a shared region rather than on the bandwidth part of one UE.

Format 4_2

DCI format 4_2 is used for the scheduling of PDSCH for multicast in DL cell. The definition reads the same as the one for format 4_1, and the two are separated by what they carry rather than by what they schedule.

The pattern is the one DCI 1_1 and DCI 1_2 already establish on this page. One format of a pair carries more fields and the other carries fewer, so a network can choose what a grant costs. Format 4_2 is the one with the wider field set of the two multicast formats.

The CRC is scrambled by a G-RNTI for multicast, or by a G-CS-RNTI configured by MBS-RNTI-SpecificConfig, exactly as for format 4_1.

• Its definition matches format 4_1 word for word : both are defined as the scheduling of PDSCH for multicast in DL cell. The split is in the field set.
• It is the fuller of the two multicast formats : pdsch-ConfigMulticast carries a maxNrofCodeWordsScheduledByDCI, and a second transport block appears only when that equals 2.
• The rate matching indicator reaches it : the groups in pdsch-ConfigMulticast are read by format 4_2, which is one of the four formats carrying that field.
• The identities are the same as for format 4_1 : G-RNTI for a dynamic multicast grant and G-CS-RNTI for a configured one.

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. A field the format does not define cannot be configured into existence. The format fixes the maximum, and everything after it only removes bits.

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 constant terms are the ones tied to a fixed meaning, such as the single bit that separates a downlink format from an uplink one.

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 bandwidth part is therefore the largest single influence on DCI size. A bandwidth part switch can change the length of the same format.

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. Two cells on the same release can therefore monitor one format at two different lengths. That is what makes DCI 1_2 and 0_2 behave as they do.

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