Uplink Frequency Domain Resource Allocation In a Nutshell

There are more than one frequency domain resource allocation types in uplink, both in LTE and NR. Some are more common and popular than the others. The "popularity" is a matter of which type serves best the purpose of coverage or capacity, though also a matter of UE capability, i.e. whether UE supports certain less common type or not. The diagram below shows the the uplink resource allocation types per RAT and practical implications of them in terms of how and how many resource blocks are allocated in uplink for a UE:

NR Type 0:

• All UE support this type, i.e. a mandatory UE capability
• Hardly ever used, if any, in 5G networks nowadays

NR Type 1:

• All UE support this type, i.e. a mandatory UE capability
• Most common, if not the only practically used type in 5G
• RIV is used for uplink frequency domain resource allocation in case of either waveform type, only the possible RIV values may differ per waveform type
• NR UL resource allocation type can be explicitly read in the RRC Reconfiguration message from pusch-Config parameter:

pusch-Config  
    setup  
       txConfig = codebook
       dmrs-UplinkForPUSCH-MappingTypeA  
          setup  
             dmrs-AdditionalPosition = pos1
             transformPrecodingDisabled  
             transformPrecodingEnabled  
       pusch-PowerControl  
          p0-AlphaSets[0]  
             p0_PUSCH_AlphaSetId = 0
             p0 = 3
             alpha = alpha1
       resourceAllocation = resourceAllocationType1        

• If transformPrecoder is disabled in the configured pusch-Config, then the waveform to be used in uplink is CP-OFDM and any integer number of contiguous PRBs can be allocated to the UE:

pusch-Config
    setup  
    ......
    ......
      mcs-Table = qam256
      mcs-TableTransformPrecoder = qam256
      transformPrecoder = disabled        

• If transformPrecoder is enabled in the configured pusch-Config, then the waveform to be used in uplink is DFT-S-OFDM and, similar to the LTE Uplink Resource allocation type 0, according to 6.3.1.4 Transform precoding of 3GPP TS 38.211, only certain valid integer number of contiguous PRBs can be allocated to the UE:

pusch-Config
    setup  
    ......
    ......
      mcs-Table = qam256
      mcs-TableTransformPrecoder = qam256
      transformPrecoder = enabled        

• The valid numbers are:1 2 3 4 5 6 8 9 10 12 15 16 18 20 24 25 27 30 32 36 40 45 48 50 54 60 64 72 75 80 81 90 96 100 108 120 125 128 135 144 150 160 162 180 192 200 216 225 240 243 250 256 270
• DFT-S-OFDM waveform use may cause certain "loss" of allocated PRBs compared to what CP-OFDM would otherwise provide, but what matters more is that DFT-S-OFDM waveform provides better coverage in uplink, which is much more important for cell edge uplink performance

LTE Type 0:

• See 8.1.1 Uplink Resource allocation type 0 of 3GPP TS 36.213 for details
• All UE support this type, i.e. a mandatory UE capability
• Most commonly used type
• There is no way to deduce uplink resource allocation to be used in RRC Connection Reconfiguration message, the type in use is dynamically assigned in the corresponding Resource Allocation Type bit of the DCI format 0 PDCCH message
• All the details can be found in LTE Uplink Resource allocation type 0 article
• RIV is used for uplink frequency domain resource allocation

LTE Type 1:

• See 8.1.2 Uplink Resource allocation type 1 of 3GPP TS 36.213 for details
• Subject to UE capability, per supported frequency band at that:

rf_Parameters  
      supportedBandListEUTRA[0]  
         bandEUTRA = 1
         halfDuplex = FALSE
      supportedBandListEUTRA[1]  
         bandEUTRA = 7
         halfDuplex = FALSE
      supportedBandListEUTRA[2]  
         bandEUTRA = 3
         halfDuplex = FALSE
      supportedBandListEUTRA[3]  
         bandEUTRA = 28
         halfDuplex = FALSE
      supportedBandListEUTRA[4]  
         bandEUTRA = 8
         halfDuplex = FALSE
      supportedBandListEUTRA[5]  
         bandEUTRA = 5
         halfDuplex = FALSE
      supportedBandListEUTRA[6]  
         bandEUTRA = 38
         halfDuplex = FALSE
      supportedBandListEUTRA[7]  
         bandEUTRA = 40
         halfDuplex = FALSE
nonCriticalExtension  
            ue_Category_v1020 = 7
            phyLayerParameters_v1020  
               multiClusterPUSCH_WithinCC_r10 = supported
               nonContiguousUL_RA_WithinCC_List_r10[0]  
               nonContiguousUL_RA_WithinCC_List_r10[1]  
               nonContiguousUL_RA_WithinCC_List_r10[2]  
                  nonContiguousUL_RA_WithinCC_Info_r10 = supported
               nonContiguousUL_RA_WithinCC_List_r10[3]  
               nonContiguousUL_RA_WithinCC_List_r10[4]  
               nonContiguousUL_RA_WithinCC_List_r10[5]  
                  nonContiguousUL_RA_WithinCC_Info_r10 = supported
               nonContiguousUL_RA_WithinCC_List_r10[6]  
               nonContiguousUL_RA_WithinCC_List_r10[7]gdtrg        

• For example, above is an excerpt from the UE capability message of a flagship model of a major mobile phone brand. Even though the UE supports LTE frequency bands 1, 7, 3, 28, 8, 5, 38 and 40, multi-clustered PUSCH allocation (Type 1) is supported only in the bands 3 and 5, i.e. 1800MHz and 850MHz.
• There is no way to deduce uplink resource allocation to be used in RRC Connection Reconfiguration message, the type in use is dynamically assigned in the Resource Allocation Type bit of the DCI format 0 PDCCH message. Please note that when the Resource Allocation Type bit of the DCI format 0 PDCCH message is set to 1, indicating Resource Allocation Type 1 being used, the Frequency Hopping Flag of the same PDCCH message is concatenated with the Resource Block Allocation to generate a bit string of sufficient length to signal the resource block allocation.
• The concatenated Resource Block Allocation with Frequency Hopping Flag bits create a combinatorial index r corresponding to a starting and ending RBG index of resource block set 1 (the first cluster), and resource block set 2 (the second cluster) respectively (see 8.1.2 Uplink Resource allocation type 1 of 3GPP TS 36.213 for details). Essentially, what is usually RIV in the DCI format 0 PDCCH message, is a combinatorial index r in case of the multi-clustered PUSCH allocation type.

• See example below:

• In the example above the assumed LTE channel bandwidth is 10MHz with RBG size 3 PRBs, there are two allocated clusters of 2 and 6 RBG blocks correspondingly, and the total sum makes for the compliant 24 PRBs. By the way the r value for this particular allocation would be 1243, if my maths is correct (which is no guarantee). Brushing up on binomial coefficient calculation may be needed to be able to calculate the combinatorial index r - see Binomial coefficient - Wikipedia. Let's see how I got that hopefully correct r value:

To keep this article truly in a nutshell, a lot of simplification, omissions and assumptions are made, e.g. it is assumed you are familiar with RBG concept and its dependencies, or what is RIV in the DCI message and its calculation principles.