MCS / TBS / Code Rate  in a Nutshell

This page answers one question. Given an MCS index carried in a DCI, how many information bits does the transport block hold? The chain is short to describe and long to compute. The MCS index selects a modulation order and a target code rate. Those two produce an intermediate bit count named N_info. N_info is then quantised into the transport block size.

MCS / TBS / Code Rate  in Detail

The concept of MCS (Modulation Coding Scheme), Code Rate, TB (Transport Block) and TBS (Transport Block Size) are same as LTE MCS, Code Rate, TBS. What differs is the last step. LTE looks the transport block size up in a table. NR computes it, and that computation is the part that causes most of the confusion.

• Overall Steps to determin Qm, Code Rate, RV and TBS
•   PDSCH Transport Block Size Determination
•   Calculate N_info
•   Calculate TBS from N_info
•   PUSCH Transport Block Size Determination
•   Modulation order and target code rate determination
•   Transport block size determination
• Case 1 : I_MCS is NOT in 'reserved' range
• Case 2 : I_MCS is in 'reserved' range.
• Max Throughput Estimation
• Method 1 : based on 38.306
• Method 2 : based on TBS

The four quantities in the title sit in a fixed order. Each one is derived from the one before it.

MCS is an index and nothing else. It is five bits in the DCI, and it selects one row of one table.

That row supplies two numbers. The first is the modulation order Qm, which is the bits carried by one modulation symbol. The second is the target code rate R, written in the tables as R x 1024.

TBS is the payload of the transport block, counted in bits. It is not simply R times the coded bits available, because the transport block size is quantised. The specification rounds it to a value that divides cleanly into LDPC code blocks.

So the code rate the decoder actually works at differs from R. R is a target, and its job is to size the transport block. Once TBS is fixed, the real code rate follows from TBS plus the CRC bits, divided by the coded bits the grant provides.

One consequence follows immediately. An MCS index means nothing until the table is known. MCS 20 is Qm 6 with a spectral efficiency of 3.3223 in 38.214 Table 5.1.3.1-1, and Qm 8 with a spectral efficiency of 5.3320 in Table 5.1.3.1-2.

Release 17 then added a fourth table for PDSCH, 38.214 Table 5.1.3.1-4, and it changes two of the numbers quoted at the top of this page. Qm reaches 10 there, because the table carries 1024QAM. The usable index range stops at 26, and 27 through 31 are reserved. Its highest spectral efficiency is 9.2578 against 7.4063 in Table 5.1.3.1-2. That is a factor of exactly 1.25, at the same 948/1024 code rate.

• MCS is only an index : Five bits in the DCI select one row, and the row supplies the modulation order and the target code rate.
• The table has to be known first : MCS 20 is Qm 6 in Table 5.1.3.1-1 and Qm 8 in Table 5.1.3.1-2, so the index alone carries no meaning.
• The target code rate is not the real one : R sizes the transport block, and the rate the decoder works at follows from TBS and the coded bits available.
• NR computes TBS where LTE looked it up : The quantisation steps exist so that the result divides cleanly into LDPC code blocks.
• Release 17 added a fourth PDSCH table : 38.214 Table 5.1.3.1-4 carries Qm 10, stops at MCS 26, and reaches 9.2578 bit/s/Hz.

Overall Steps to determin Qm, Code Rate, RV and TBS

Three steps take a DCI to a transport block size. Each step hides a different kind of work, and only the third is arithmetic. The list below is the outline, and the sections after it work through the third step in full.

Step 1 : Read MCS from DCI and determin Qm (Modulation Scheme) and R(Code Rate) from following tables

•   38.214-Table 5.1.3.1-1
•   38.214-Table 5.1.3.1-2
•   38.214-Table 5.1.3.1-3

NOTE : The problem is to figure out which of the above tables to be applied. This is a pretty complicated and confusing procedure to pick up a specific table. I summerized this table picking criteria here.

Step 2 : Read RV(Redundancy Version) from DCI

Step 3 : Determine TBS (Transport block Size) based on following factors

•   Number of Layers
•   Number of PRB
•   TBS dermining process described here (PDSCH TBS, PUSCH TBS)

The three steps differ in what they cost.

Step 1 is a table lookup, and the difficulty is choosing the table rather than reading it. The choice depends on the RNTI that scrambled the DCI CRC, on the DCI format that carried the grant, and on which mcs-Table parameter the network configured. A DCI carrying MCS 20 is meaningless until all three are known.

Step 2 is the cheapest of the three. RV selects which part of the circular buffer is transmitted, and it does not change the transport block size. A retransmission with a different RV carries the same TBS as the first transmission.

Step 3 is the long one, and the rest of this page is about it. It runs in two stages. The first stage counts the resource elements the grant provides and turns them into N_info. The second stage quantises N_info into a transport block size.

Keeping those two stages apart helps while reading the sections below. The first stage is arithmetic on the grant, and every term in it comes from the scheduling decision. The second stage is pure quantisation, and it depends only on N_info and on the code rate.

• Choosing the table is the hard part of Step 1 : The RNTI, the DCI format and the configured mcs-Table parameter decide it together.
• RV does not change TBS : Redundancy version selects part of the circular buffer, so a retransmission carries the same transport block size.
• Step 3 runs in two stages : N_info is computed from the grant, and then quantised into a transport block size.
• The quantisation has a reason : It makes the transport block divide cleanly into LDPC code blocks, which is why the thresholds 3824 and 8424 appear in the flow chart.

PDSCH Transport Block Size Determination

NR MCS and Code Rate are determined by a predefined table as in 38.214 - Table 5.1.3.1-1 and 38.214 - Table 5.1.3.1-2, which is pretty straight forward. However, determining TBS (Transport block size) in NR is more complicated than the one in LTE. In case of LTE, all the possibility of TBS are precalculated and listed as a big table. However, in NR the TBS determination process is described as a sequence of algorithm as summarized below (I think it will take a while to get familiar with this process).

< Calculate N_info >

As you see in the process illustrated above, the initial input for this algorithm is Ninfo. However, to figure out this Ninfo also requires long calculation process as below.

< 38.214  - Table 5.1.3.1-1: MCS index table 1 for PDSCH >

< 38.214 - Table 5.1.3.1-2: MCS index table 2 for PDSCH >

< 38.214 - Table 5.1.3.1-3: MCS index table 3 for PDSCH >

< 38.214  - Table 5.1.3.2-1: TBS for N_info <= 3824  >

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

< Calculate TBS from N_info >

This is an illustration based on 38.214 - 5.1.3.2 Transport block size determination.

PUSCH Transport Block Size Determination

PUSCH Transport block size is influenced by RRC Parameters at the stage of determining Modulation Order and Code Rate and this makes it so difficult and complicated to understand the whole process of TBS(Transport Size) Determination. The RRC parameters involved in this process is highlighted in red as shown below.

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

PUSCH-Config ::= SEQUENCE {

    dataScramblingIdentityPUSCH                 INTEGER (0..1023) OPTIONAL,

    txConfig                                    ENUMERATED {codebook, nonCodebook}

    dmrs-UplinkForPUSCH-MappingTypeA            SetupRelease { DMRS-UplinkConfig }

    dmrs-UplinkForPUSCH-MappingTypeB            SetupRelease { DMRS-UplinkConfig }

    pusch-PowerControl                          PUSCH-PowerControl

    frequencyHopping                            ENUMERATED {intraSlot, interSlot}

    frequencyHoppingOffsetLists                 SEQUENCE (SIZE (1..4)) OF

                                                     INTEGER (1.. maxNrofPhysicalResourceBlocks-1)

    resourceAllocation                          ENUMERATED { resourceAllocationType0,

                                                             resourceAllocationType1,

                                                             dynamicSwitch},

    pusch-TimeDomainAllocationList              SetupRelease {

                                                         PUSCH-TimeDomainResourceAllocationList

                                                }

    pusch-AggregationFactor                     ENUMERATED { n2, n4, n8 }

    mcs-Table                                   ENUMERATED {qam256, qam64LowSE}

    mcs-TableTransformPrecoder                  ENUMERATED {qam256, qam64LowSE}

    transformPrecoder                           ENUMERATED {enabled, disabled}

    codebookSubset                              ENUMERATED {fullyAndPartialAndNonCoherent,

                                                            partialAndNonCoherent,

                                                            nonCoherent}

    maxRank                                        INTEGER (1..4)

    rbg-Size                                          ENUMERATED { config2}

    uci-OnPUSCH                                 SetupRelease { UCI-OnPUSCH }

    tp-pi2BPSK                                  ENUMERATED {enabled}

    ...

}

ConfiguredGrantConfig ::= SEQUENCE {

   frequencyHopping ENUMERATED                 {intraSlot, interSlot} ,

    cg-DMRS-Configuration                       DMRS-UplinkConfig,

    mcs-Table                                   ENUMERATED {qam256, qam64LowSE}

    mcs-TableTransformPrecoder                  ENUMERATED {qam256, qam64LowSE}

    uci-OnPUSCH SetupRelease                    { CG-UCI-OnPUSCH } OPTIONAL,

    resourceAllocation                          ENUMERATED { resourceAllocationType0,

                                                             resourceAllocationType1,

                                                             dynamicSwitch },

    rbg-Size                                    ENUMERATED {config2},

    powerControlLoopToUse                       ENUMERATED {n0, n1},

    p0-PUSCH-Alpha                              P0-PUSCH-AlphaSetId,

    transformPrecoder                           ENUMERATED {enabled, disabled},

    nrofHARQ-Processes                          INTEGER(1..16),

    repK                                        ENUMERATED {n1, n2, n4, n8},

    repK-RV                                     ENUMERATED {s1-0231, s2-0303, s3-0000},

    periodicity                                 ENUMERATED {

                                                    sym2, sym7, sym1x14, sym2x14, sym4x14,

                                                    sym5x14, sym8x14, sym10x14, sym16x14,

                                                    sym20x14,sym32x14, sym40x14, sym64x14,

                                                    sym80x14, sym128x14, sym160x14, sym256x14,

                                                    sym320x14, sym512x14,sym640x14, sym1024x14,

                                                    sym1280x14, sym2560x14, sym5120x14,sym6,

                                                    sym1x12, sym2x12, sym4x12, sym5x12,

                                                    sym8x12, sym10x12, sym16x12, sym20x12,

                                                    sym32x12,sym40x12, sym64x12, sym80x12,

                                                    sym128x12, sym160x12, sym256x12, sym320x12,

                                                    sym512x12, sym640x12,sym1280x12, sym2560x12

                                                },

    configuredGrantTimer                        INTEGER (1..64) OPTIONAL, -- Need R

    rrc-ConfiguredUplinkGrant                   SEQUENCE {

                                                   timeDomainOffset          INTEGER (0..5119),

                                                   timeDomainAllocation      INTEGER (0..15),

                                                   frequencyDomainAllocation BIT STRING (SIZE(18)),

                                                   antennaPort               INTEGER (0..31),

                                                   dmrs-SeqInitialization    INTEGER (0..1),

                                                   precodingAndNumberOfLayers  INTEGER (0..63),

                                                   srs-ResourceIndicator       INTEGER (0..15),

                                                   mcsAndTBS                   INTEGER (0..31),

                                                   frequencyHoppingOffset      

                                                                INTEGER (1.. maxNrofPhysicalResourceBlocks-1)

                                                   pathlossReferenceIndex        

                                                                INTEGER (0..maxNrofPUSCH-PathlossReferenceRSs-1)

                                                    ...

                                               } OPTIONAL, -- Need R

    ...

}

Both listings above are still accurate in Release 19. Every field quoted is present in 38.331 v19.3.0, and the order is unchanged. What later releases added is a second copy of the modulation table fields, and the copies are what decide the table in Step 1 above.

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

PUSCH-Config ::= SEQUENCE {

    ....

    mcs-TableDCI-0-2-r16 ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

    mcs-TableTransformPrecoderDCI-0-2-r16 ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

    ....

}

PDSCH-Config ::= SEQUENCE {

    ....

    mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

    mcs-TableDCI-1-2-r16 ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

    mcs-Table-r17 ENUMERATED {qam1024} OPTIONAL, -- Need R

    mcs-TableDCI-1-2-r17 ENUMERATED {qam1024} OPTIONAL, -- Need R

    ....

}

Release 16 added one table field per compact DCI format. So a UE can be told to use one MCS table when the grant arrives in DCI format 0_1. It can be told to use a different table when the same grant arrives in DCI format 0_2. Reading mcs-Table on its own is therefore not enough to decide the table for a given grant.

Release 17 added the two fields that select the 1024QAM table. When mcs-Table-r17 is set to qam1024, and the PDSCH is scheduled by DCI format 1_1 or 1_3 with a CRC scrambled by C-RNTI, the UE reads 38.214 Table 5.1.3.1-4. That is the table where Qm reaches 10.

Three things follow for anyone decoding a live grant. Every field quoted above is still current in 38.331 v19.3.0. The table in use depends on the DCI format as well as on the configuration. And 1024QAM has its own selector, which is mcs-Table-r17.

< Modulation order and target code rate determination >

I created following table based on the descriptions in 38.214-6.1.4.1(v15.3 - Oct 2018).

< Transport block size determination >

I created following summary based on the descriptions in 38.214-6.1.4.2 (v15.3 - Oct 2018).

Case 1 : I_MCS is NOT in 'reserved' range.

NOTE : The condition for this case is described in 38.214-6.1.4.2 (v15.3 - Oct 2018) as follows. At first, it looks very confusing. It looked like three different 'if statement' with conflicting condition. But looking more closely, I realized all of these three lines makes up a single 'if statement'. You see all of these three lines are combined by 'or'.

- 0 <= I_MCS <≤ 27 and transform precoding is disabled and Table 5.1.3.1-2 is used, or

- 0 <≤ I_MCS <≤ 28 and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or

- 0 <≤ I_MCS <≤ 27 and transform precoding is enabled

First Calculate N'_RE using following formula

Next Calculate the total number of REs for PUSCH as follows.

Next Calculate Ninfo as follows :

Next step is same as downlink TBS determination process as shown below.

Case 2 : I_MCS is in 'reserved' range.

Max Throughput Estimation

There are roughly two approaches to estimate the max throughput. One of the most popular  or best known method is to use the formula specified in 38.306-4.1.2. But this method would tend to give much higher value than you normally achieve in real life testing since it is hard to take into consider various overhead that you face.

In my opinion, more accurate method is to estimate TBS for each slot within a radio frame and multiply the number with the number of radio frames per second.

Method 1 : based on 38.306

    This method is explained in a different page here.

Method 2 : based on TBS

    This is based on the transport block size (TBS) estimation explained in this page. As you see in this page, this method goes through a little bit complicated process, so I wrote a Octave script to estimate the throughput as shown below.

NOTE : This is not the perfect/complete script. For simplicity, I only implemented the high throughput path as indicated by red arrow below. I used Code Rate (R) value from 38.214 -Table 5.1.3.1-1 and Table 5.1.3.1-2, but real code rate can vary a little bit from the value in the table... but you can use the table value as a rough estimator.

Following is the result of an example run

Reference

[1]