Resource Allocation in Time Domain and Ack/Nack Response Timing in a Nutshell

Resource Allocation in Time Domain and Ack/Nack Response Timing

As in LTE, in NR as well Resource Allocation should be defined both in Time domain and Frequency Domain. In LTE, we didn't care much about the time domain resource allocation since they are assigned by a fixed/predefined rule, but in NR the time domain resource allocation is determined by much more complicated rule than in LTE whereas freuqency domain resource allocation is almost same as in LTE.

Following is the list of topics related to the resource allocation in Time Domain.

• PDSCH - Time Domain Allocation (DCI - PDSCH Timing) : K0
• Example 1
• Example 2
• PDSCH - Ack/Nack Timing : K1
• PUSCH - Time Domain Allocation : K2
• UE PDSCH Processing Procedure Time : N1
• UE PUSCH preparation procedure time : N2
• How do the six parameters fit together ?
• How does the UE know which row of the allocation table to use ?
• What is the difference between mapping type A and type B ?
• How does subcarrier spacing change these numbers ?
• What are the actual N1 and N2 values ?

As mentioned above, frequency domain resource allocation is very similar to LTE. Mainly determined by bitmap or RIV depending of Resource Allocation Type. This part will be described in a separate page titled Resource Allocation Type.

PDSCH - Time Domain Allocation (DCI - PDSCH Timing) : K0

Following is the illustration showing the Time Domain resource allocation for PDSCH based on 38.214 - 5.1.2.1 Resource allocation in time domain. When the subcarrier spacing of PDSCH and PDCCH is different, the time delay between DCI slot and PDSCH slot is a little bit complicated as shown below, but when the subcarrier spacing of PDSCH and PDCCH is same the time delay between DCI slot and PDSCH slot becomes K0.

NOTE : In most case, we configure that PDSCH subcarrier spacing is same as PDCCH subcarrier spacing, so you can say K0 = Time Delay between DCI slot and PDSCH slot  

Following is the RRC parameters determining k0. SLIV determination is a pretty complicated process. so I created a separate page for this, refer to this page.  PDSCH-TimeDomainResourceAllocation is an IE(Information Element) of PDSCH-Config and PDSCH-ConfigCommon. It is defined as an element (a kind of array element) of an IE called pdsch-AllocationList.  Once this array(pdsch-AllocationList) is defined in RRC message, which elements of the array is used for each PDSCH scheduling is determined by the field called Time domain resource assignment in DCI 1_0 and DCI 1_1.

PDSCH-TimeDomainResourceAllocation ::= SEQUENCE {

   k0                                  INTEGER(0..32)        OPTIONAL, -- Need S

   mappingType                         ENUMERATED {typeA, typeB},

   startSymbolAndLength                INTEGER (0..127)  // SLIV

}

PDSCH-TimeDomainResourceAllocation-r16 ::= SEQUENCE {

   k0-r16                                  INTEGER(0..32) OPTIONAL, -- Need S

   mappingType-r16                   ENUMERATED {typeA, typeB},

   startSymbolAndLength-r16       INTEGER (0..127),

   repetitionNumber-r16              ENUMERATED {n2, n3, n4, n5, n6, n7, n8, n16}

                                                                    OPTIONAL,--Cond Formats1-0and1-1

   ...,

   [[

   k0-v1710 INTEGER(33..128)     OPTIONAL -- Need S

   ]],

   [[

   repetitionNumber-v1730    ENUMERATED {n2, n3, n4, n5, n6, n7, n8, n16}

                                                   OPTIONAL -- Cond Format1-2

   ]]

}

NOTE : k0-v1710 is only applicable for PDSCH SCS of 480 kHz and 960 kHz. When the field is absent the UE applies the value 0.

Release 17 added a second allocation list, used when one DCI schedules several PDSCHs at once. It is configured by pdsch-TimeDomainAllocationListForMultiPDSCH-r17 in PDSCH-Config, and each of its rows carries a list of ordinary allocations rather than a single one.

MultiPDSCH-TDRA-List-r17 ::= SEQUENCE (SIZE(1.. maxNrofDL-AllocationsExt-r17)) OF MultiPDSCH-TDRA-r17

MultiPDSCH-TDRA-r17 ::= SEQUENCE {

   pdsch-TDRA-List-r17    SEQUENCE (SIZE(1..maxNrofMultiplePDSCHs-r17)) OF PDSCH-TimeDomainResourceAllocation-r16,

   ...

}

NOTE : each row of MultiPDSCH-TDRA-r17 holds up to maxNrofMultiplePDSCHs-r17 entries, and every entry is a PDSCH-TimeDomainResourceAllocation-r16. One DCI therefore selects one row and schedules every PDSCH that the row describes.

NOTE : repetitionNumber Indicates the number of PDSCH transmission occasions for slot-based repetition scheme in IE RepetitionSchemeConfig.

PDSCH-Config ::= SEQUENCE {

   ...

   repetitionSchemeConfig-r16                SetupRelease { RepetitionSchemeConfig-r16} OPTIONAL -- Need M

   ]],

   [[

   repetitionSchemeConfig-v1630             SetupRelease { RepetitionSchemeConfig-v1630} OPTIONAL -- Need M

   ]],

   ...

}

RepetitionSchemeConfig-r16 ::= CHOICE {

   fdm-TDM-r16                                    SetupRelease { FDM-TDM-r16 },

   slotBased-r16                                   SetupRelease { SlotBased-r16 }

}

RepetitionSchemeConfig-v1630 ::= SEQUENCE {

   slotBased-v1630                               SetupRelease { SlotBased-v1630 }

}

FDM-TDM-r16 ::= SEQUENCE {

   repetitionScheme-r16                        ENUMERATED {fdmSchemeA, fdmSchemeB,tdmSchemeA },

   startingSymbolOffsetK-r16                 INTEGER (0..7) OPTIONAL -- Need R

}

SlotBased-r16 ::= SEQUENCE {

   tciMapping-r16                                ENUMERATED {cyclicMapping, sequentialMapping},

   sequenceOffsetForRV-r16                  INTEGER (1..3)

}

SlotBased-v1630 ::= SEQUENCE {

   tciMapping-r16                               ENUMERATED {cyclicMapping, sequentialMapping},

   sequenceOffsetForRV-r16                INTEGER (0)

}

Example 1 >

This example is based on 38.523-3 7.1.2.2.2.

Both examples use the same pdsch-AllocationList, and only the DCI value differs between them. The list holds two rows. Row 0 omits k0, which means the UE applies 0. Row 1 sets k0 to 1. Both rows use mapping type A. In this first example the Time domain resource assignment field carries 0, so the UE reads row 0. K0 is therefore 0, and the PDSCH lands in the same slot as the DCI that scheduled it. The SLIV of 58 gives a start symbol of 2 and a length of 5. Symbol 2 is the first symbol after the two-symbol CORESET.

Example 2 >

This example is based on 38.523-3 7.1.2.2.2.

The configuration here is identical to Example 1. Only the DCI has changed, and it now carries 1 in the Time domain resource assignment field. That selects row 1, where k0 is 1. The PDSCH therefore moves into the slot after the DCI. The SLIV of 56 gives a start symbol of 0 and a length of 5. The allocation therefore begins at the slot boundary. Nothing else was reconfigured, and that is the point of the pair. One DCI field moved the allocation into a different slot and to a different start symbol.

The two rows are not an arbitrary pair. Row 0 puts a k0 of 0 beside a start symbol of 2, which leaves the first two symbols of the slot for the CORESET. Row 1 puts a k0 of 1 beside a start symbol of 0, because that allocation has already moved into the following slot. An allocation list is usually built this way, with each start symbol chosen to suit the slot that its own k0 value lands in.

• One DCI field chose everything : The same list produced two different allocations, and only the Time domain resource assignment value changed.
• An omitted k0 means 0 : Row 0 leaves the field out, and the UE applies 0 rather than treating the row as invalid.
• K0 picks the slot and SLIV picks the symbols : Neither one alone places the PDSCH, and both arrive from the same row.
• The start symbol is chosen against the CORESET : A k0 of 0 has to start after the PDCCH, and a k0 of 1 does not.

PDSCH - Ack/Nack Timing : K1

PDSCH-Ack/Nack Timing defines the time gap between PDSCH transmission and the reception of the PUCCH that carries ACK/NACK for the PDSCH.

Simply put, K1 indicates the time delay between PDSCH slot and UCI (Ack/Nack) slot

PUCCH-Config ::=        SEQUENCE {

...

    dl-DataToUL-ACK        SEQUENCE (SIZE (1..8)) OF INTEGER (0..15)   OPTIONAL,   -- Need M

...

    dl-DataToUL-ACK-r16    SetupRelease { DL-DataToUL-ACK-r16 }

...

   dl-DataToUL-ACK-DCI-1-2-r16      SetupRelease { DL-DataToUL-ACK-DCI-1-2-r16}

   ]],

   [[

   ul-AccessConfigListDCI-1-2-r17    SetupRelease { UL-AccessConfigListDCI-1-2-r17 }

   dl-DataToUL-ACK-r17    SetupRelease { DL-DataToUL-ACK-r17 }

   dl-DataToUL-ACK-DCI-1-2-r17    SetupRelease { DL-DataToUL-ACK-DCI-1-2-r17}

   ul-AccessConfigListDCI-1-1-r17    SetupRelease { UL-AccessConfigListDCI-1-1-r17 }

   dl-DataToUL-ACK-v1700    SetupRelease { DL-DataToUL-ACK-v1700 }

   dl-DataToUL-ACK-MulticastDCI-Format4-1-r17    SetupRelease { DL-DataToUL-ACK-MulticastDCI-Format4-1-r17 }

   ]]

}

DL-DataToUL-ACK-r16 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (-1..15)

DL-DataToUL-ACK-DCI-1-2-r16 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (0..15)

DL-DataToUL-ACK-r17 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (-1..127)

DL-DataToUL-ACK-v1700 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (16..31)

DL-DataToUL-ACK-DCI-1-2-r17 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (0..127)

DL-DataToUL-ACK-MulticastDCI-Format4-1-r17 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (0..15)

NOTE : dl-DataToUL-ACK-r17 and dl-DataToUL-ACK-DCI-1-2-r17 are only applicable for SCS of 480 kHz or 960 kHz, which is why their upper bound is 127 rather than 15.

NOTE : where dl-DataToUL-ACK-r16, dl-DataToUL-ACK-r17 or dl-DataToUL-ACK-v1700 is signalled, the UE ignores dl-DataToUL-ACK without a suffix.

NOTE : You may refer to this example in protocol log to see how this works.

PUSCH - Time Domain Allocation : K2

Following is the illustration showing the Time Domain resource allocation for PUSCH based on 38.214 - 6.1.2.1 Resource allocation in time domain. When the subcarrier spacing of PUSCH and PDCCH is different, the time delay between DCI slot and PUSCH slot is a little bit complicated as shown below, but when the subcarrier spacing of PUSCH and PDCCH is same the time delay between DCI slot and PUSCH slot becomes K2.

NOTE : In most case, we configure that PDSCH subcarrier spacing is same as PDCCH subcarrier spacing, so you can say K2 = Time Delay between DCI slot and PUSCH slot

Following is the RRC parameters determining k2. SLIV determination is a pretty complicated process. so I created a separate page for this, refer to this page.

PUSCH-TimeDomainResourceAllocation ::=  SEQUENCE {

    k2                                  INTEGER (0..32)                          

    mappingType                         ENUMERATED {typeA, typeB},

    startSymbolAndLength                INTEGER (0..127) // SLIV

}

PUSCH-TimeDomainResourceAllocation-r16 ::= SEQUENCE {

   k2-r16                   INTEGER(0..32) OPTIONAL, -- Need S

   puschAllocationList-r16  SEQUENCE (SIZE(1..maxNrofMultiplePUSCHs-r16)) OF PUSCH-Allocation-r16,

...

}

PUSCH-Allocation-r16 ::= SEQUENCE {

   mappingType-r16            ENUMERATED {typeA, typeB} OPTIONAL, -- Cond NotFormat01-02-Or-TypeA

   startSymbolAndLength-r16   INTEGER (0..127) OPTIONAL, -- Cond NotFormat01-02-Or-TypeA

   startSymbol-r16            INTEGER (0..13) OPTIONAL, -- Cond RepTypeB

   length-r16                 INTEGER (1..14)  OPTIONAL, -- Cond RepTypeB

   numberOfRepetitions-r16    ENUMERATED {n1, n2, n3, n4, n7, n8, n12, n16}

                                                       OPTIONAL, -- Cond Format01-02

...

   [[

   numberOfRepetitionsExt-r17   ENUMERATED {n1, n2, n3, n4, n7, n8, n12, n16, n20, n24, n28,

                               n32, spare4, spare3, spare2, spare1}

                               OPTIONAL, -- Cond Format01-02-For-TypeA

   numberOfSlotsTBoMS-r17   ENUMERATED {n1, n2, n4, n8, spare4, spare3, spare2, spare1}

                               OPTIONAL, -- Need R

   extendedK2-r17   INTEGER (0..128)   OPTIONAL -- Cond MultiPUSCH

   ]]

}

UE PDSCH Processing Procedure Time : N1

After UE completed the reception of PDSCH, it cannot send HARQ ACK/NACK right away because it needs some time to process the received data. The time span that UE requires to process the received PDSCH is called Tproc as shown in the following illustration and N1 is a major factor determining the Tproc. Roughly speaking, you can take N1 almost same as PDSCH processing time. Depending on the UE performance, this Tproc may vary (i.e, Tproc would be shorter with high performance UE comparing to poor performing UE). When network configures K1 and PUCCH location, it is important that the configuration gives enough time for UE to complete the process. That is, network should configure K1 and PUCCH in such that Tgap_symb is greater than Tproc.

NOTE : I mentioned that the processing time would vary depending on UE performance. Then, the question is how Network get to know the UE peformance. It is via UE capability information. UE is expected to notify its capability of how fast it can process PDSCH (N1) via UE Capability Information message. In this report, UE does not send any specific N1 value. As shown above, there are two tables of N1 value. Every UE should meet Capability 1 requirement by default and it is optional to meet the capability 2 table. Whether a UE support capability 2 table or not is informed to Network via UE capability Information message as shown below.

FeatureSetDownlink-v1540 ::= SEQUENCE {

    oneFL-DMRS-TwoAdditionalDMRS-DL          ENUMERATED {supported} OPTIONAL,

    additionalDMRS-DL-Alt                    ENUMERATED {supported} OPTIONAL,

    twoFL-DMRS-TwoAdditionalDMRS-DL          ENUMERATED {supported} OPTIONAL,

    oneFL-DMRS-ThreeAdditionalDMRS-DL        ENUMERATED {supported} OPTIONAL,

    pdcch-MonitoringAnyOccasionsWithSpanGap   SEQUENCE {

        scs-15kHz                            ENUMERATED {set1, set2, set3} OPTIONAL,

        scs-30kHz                            ENUMERATED {set1, set2, set3} OPTIONAL,

        scs-60kHz                            ENUMERATED {set1, set2, set3} OPTIONAL,

        scs-120kHz                           ENUMERATED {set1, set2, set3} OPTIONAL

    } OPTIONAL,

    pdsch-SeparationWithGap                  ENUMERATED {supported} OPTIONAL,

    pdsch-ProcessingType2 SEQUENCE {

        scs-15kHz                            ProcessingParameters OPTIONAL,

        scs-30kHz                            ProcessingParameters OPTIONAL,

        scs-60kHz                            ProcessingParameters OPTIONAL

    } OPTIONAL,

    pdsch-ProcessingType2-Limited SEQUENCE {

        differentTB-PerSlot-SCS-30kHz        ENUMERATED {upto1, upto2, upto4, upto7}

    } OPTIONAL,

    dl-MCS-TableAlt-DynamicIndication        ENUMERATED {supported} OPTIONAL

}

pdsch-ProcessingType2 : According 36.306, it is stated as follows.

Indicates whether the UE supports PDSCH processing capability 2. The UE supports it only if all serving cells are self-scheduled and if all serving cells in one band on which the network configured processingType2 use the same subcarrier spacing. This capability signalling comprises the following parameters for each subcarrier spacing supported by the UE.

• fallback indicates whether the UE supports PDSCH processing capability 2 when the number of configured carriers is larger than numberOfCarriers for a reported value of differentTB-PerSlot. If fallback = 'sc', UE supports capability 2 processing time on lowest cell index among the configured carriers in the band where the value is reported, if fallback = 'cap1-only', UE supports only capability 1, in the band where the value is reported;
• differentTB-PerSlot indicates whether the UE supports processing type 2 for 1, 2, 4 and/or 7 unicast PDSCHs for different transport blocks per slot per CC; and if so, it indicates up to which number of CA serving cells the UE supports that number of unicast PDSCHs for different TBs. The UE shall include at least one of numberOfCarriers for 1, 2, 4 or 7 transport blocks per slot in this field if pdsch-ProcessingType2 is indicated.

pdsch-ProcessingType2-Limited :

Indicates whether the UE supports PDSCH processing capability 2 with scheduling limitation for SCS 30kHz. This capability signalling comprises the following parameter.

• differentTB-PerSlot-SCS-30kHz indicates the number of different TBs per slot.

The UE supports this limited processing capability 2 only if:

1) One carrier is configured in the band, independent of the number of carriers configured in the other bands;

2) The maximum bandwidth of PDSCH is 136 PRBs;

3) N1 based on Table 5.3-2 (shown above) for SCS 30 kHz.

UE PUSCH preparation procedure time : N2

After UE recieved the UL Grant(DCI 0_x), it cannot send PUSCH right away because it needs some time to prrepare the PUSCH data. The time span that UE requires to prepare PUSCH is called Tproc as shown in the following illustration and N2 is a major factor determining the Tproc. Roughly speaking, you can take N2 almost same as PUSCH preparation time. Depending on the UE performance, this Tproc may vary (i.e, Tproc would be shorter with high performance UE comparing to poor performing UE). When network configures K2 and PUSCH location(i.e, PUSCH SLIV), it is important that the configuration gives enough time for UE to complete the preparation. That is, network should configure K2 and PUSCH in such that Tgap_symb is greater than Tproc.

NOTE : I mentioned that the processing time would vary depending on UE performance. Then, the question is how Network get to know the UE peformance. It is via UE capability information. UE is expected to notify its capability of how fast it can prepare PUSCH (N2) via UE Capability Information message. In this report, UE does not send any specific N2 value. As shown above, there are two tables of N2 value. UE notify the processing parameters for each capability table.

phy-Parameters {

   phy-ParametersCommon {

      ...

      bwp-SwitchingDelay type1,

      ...

},

featureSetsDownlink {

   {

    ...

    pdsch-ProcessingType1-DifferentTB-PerSlot {

       scs-15kHz upto2,

       scs-30kHz upto2,

       scs-60kHz upto2,

       scs-120kHz upto2

     },

...

FeatureSetUplink ::= SEQUENCE {

   featureSetListPerUplinkCC               SEQUENCE (SIZE (1.. maxNrofServingCells)) OF

                                                        FeatureSetUplinkPerCC-Id,

   scalingFactor                           ENUMERATED {f0p4, f0p75, f0p8} OPTIONAL,

   dummy3                                  ENUMERATED {supported} OPTIONAL,

   intraBandFreqSeparationUL               FreqSeparationClass OPTIONAL,

   searchSpaceSharingCA-UL                 ENUMERATED {supported} OPTIONAL,

   dummy1                                  DummyI OPTIONAL,

   supportedSRS-Resources                  SRS-Resources OPTIONAL,

   twoPUCCH-Group                          ENUMERATED {supported} OPTIONAL,

   dynamicSwitchSUL                        ENUMERATED {supported} OPTIONAL,

   simultaneousTxSUL-NonSUL                ENUMERATED {supported} OPTIONAL,

   pusch-ProcessingType1-DifferentTB-PerSlot SEQUENCE {

      scs-15kHz                            ENUMERATED {upto2, upto4, upto7} OPTIONAL,

      scs-30kHz                            ENUMERATED {upto2, upto4, upto7} OPTIONAL,

      scs-60kHz                            ENUMERATED {upto2, upto4, upto7} OPTIONAL,

      scs-120kHz                           ENUMERATED {upto2, upto4, upto7} OPTIONAL

   } OPTIONAL,

   dummy2 DummyF OPTIONAL

}

FeatureSetUplink-v1540 ::= SEQUENCE {

   zeroSlotOffsetAperiodicSRS            ENUMERATED {supported} OPTIONAL,

   pa-PhaseDiscontinuityImpacts          ENUMERATED {supported} OPTIONAL,

   pusch-SeparationWithGap               ENUMERATED {supported} OPTIONAL,

   pusch-ProcessingType2 SEQUENCE {

      scs-15kHz                          ProcessingParameters OPTIONAL,

      scs-30kHz                          ProcessingParameters OPTIONAL,

      scs-60kHz                          ProcessingParameters OPTIONAL

   } OPTIONAL,

   ul-MCS-TableAlt-DynamicIndication     ENUMERATED {supported} OPTIONAL

}

FeatureSetUplink-v1610 ::= SEQUENCE {

   pusch-RepetitionTypeB-r16 SEQUENCE {

      maxNumberPUSCH-Tx-r16              ENUMERATED {n2, n3, n4, n7, n8, n12},

      hoppingScheme-r16                  ENUMERATED {interSlotHopping, interRepetitionHopping, both}

   } OPTIONAL,

   ul-CancellationSelfCarrier-r16        ENUMERATED {supported} OPTIONAL,

   ul-CancellationCrossCarrier-r16       ENUMERATED {supported} OPTIONAL,

   ul-FullPwrMode2-MaxSRS-ResInSet-r16   ENUMERATED {n1, n2, n4} OPTIONAL,

   cbgPUSCH-ProcessingType1-DifferentTB-PerSlot-r16 SEQUENCE {

      scs-15kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-30kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-60kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-120kHz-r16                     ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL

   } OPTIONAL,

   cbgPUSCH-ProcessingType2-DifferentTB-PerSlot-r16 SEQUENCE {

      scs-15kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-30kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-60kHz-r16                      ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL,

      scs-120kHz-r16                     ENUMERATED {one-pusch, upto2, upto4, upto7} OPTIONAL

   } OPTIONAL,

How do the six parameters fit together ?

The Nutshell box lists the six parameters separately. They are easier to hold in one piece with one distinction in mind. Three of them are chosen by the scheduler, and three are not.

K0, K1 and K2 are scheduler decisions. The network picks a value for each one and signals it, and it may pick a different value for every grant. SLIV is also a scheduler decision, and it works inside a slot rather than between slots.

N1 and N2 are not decisions at all. They are floors, fixed by TS 38.214 for a given UE capability and numerology. The scheduler cannot make them smaller. What it can do is choose K1 and K2 large enough that the floors are respected. That is the whole relationship between the two groups.

One unit difference in that table causes most of the confusion. The K values count whole slots, and SLIV, N1 and N2 count symbols. A K1 of 2 is not a fixed amount of time, and neither is an N1 of 10, until the subcarrier spacing is known.

Figure 1 puts all of them on one time line, with the downlink and the uplink drawn separately.

Figure 1. The scheduler picks the K values. N1 and N2 are floors it has to respect, and they come from the UE capability rather than from any configuration.

• Three are scheduled and three are fixed : K0, K1, K2 and SLIV are chosen per grant. N1 and N2 are floors set by the specification.
• The K values count slots : They say which slot, and never where inside it.
• SLIV works inside one slot : It carries the start symbol and the length, which is the part the K values do not describe.
• N1 and N2 are symbol counts : Comparing them against a K value means converting one of the two, using the numerology.
• The scheduler respects the floors by choosing K : It cannot shorten N1 or N2. It moves the Ack/Nack or the PUSCH later instead.

How does the UE know which row of the allocation table to use ?

K0 and SLIV do not travel in the DCI as numbers. The DCI carries an index, and the index points into a table that RRC configured earlier. Getting that indirection clear makes the rest of this page easier to read.

The chain has three steps. The Time domain resource assignment field in DCI format 1_0 or 1_1 holds a row index. That index selects one entry of pdsch-TimeDomainAllocationList. The entry holds three things: k0, mappingType and startSymbolAndLength. The field is at most four bits wide, so the list holds at most sixteen rows.

The uplink works the same way. The Time domain resource assignment field in DCI format 0_0 or 0_1 selects a row of pusch-TimeDomainAllocationList. That row holds k2, mappingType and startSymbolAndLength.

A UE that has no such list still has to decode a grant, which is why the specification also defines default tables. TS 38.214 gives several of them. The RNTI, the search space and the CORESET decide which one applies. A UE reading Msg2 or SIB1 is using a default table, because dedicated configuration has not happened yet.

K1 is signalled differently, and it is worth separating. It does not come from the allocation table at all. RRC configures a list called dl-DataToUL-ACK, and a DCI field named the PDSCH-to-HARQ feedback timing indicator selects one entry of that list.

The K0 section diagram draws this indirection. The DCI field points at the table, and the table supplies both K0 and the SLIV.

• The DCI carries an index, not a value : The Time domain resource assignment field selects a row of a list that RRC configured.
• One row supplies three things : k0 or k2, the mapping type, and the start and length of the allocation.
• The list holds at most sixteen rows : The DCI field is four bits at its widest.
• Default tables cover the gap before RRC : TS 38.214 defines them, and the RNTI, search space and CORESET decide which one applies.
• K1 arrives by a different route : It is selected from dl-DataToUL-ACK by the PDSCH-to-HARQ feedback timing indicator.

What is the difference between mapping type A and type B ?

Every row of the allocation table carries a mappingType alongside k0 and the SLIV. The field appears in the RRC definitions on this page, and it decides something the SLIV alone cannot express.

The difference is where the DMRS sits. In mapping type A the DMRS position is counted from the slot boundary, at symbol 2 or symbol 3 according to dmrs-TypeA-Position. The allocation therefore has to begin near the start of the slot, because the DMRS has to fall inside it. That is why S is limited to the first four symbols.

In mapping type B the DMRS sits at the first symbol of the allocation, wherever that allocation begins. Nothing is anchored to the slot boundary. The allocation can therefore start at almost any symbol, and it is usually short.

That single difference explains the ranges the specification allows for each type.

The purpose behind type B is latency. A transmission using type A waits for a slot boundary before it can start. A transmission using type B starts at the next symbol that suits it. The uplink has the same two types, with different ranges again, and PUSCH mapping type B allows a length of one symbol upward.

Figure 2 draws both types inside a single slot of fourteen symbols.

Figure 2. Type B exists so that a transmission can start part way through a slot without waiting for the next slot boundary. That is what makes low latency scheduling possible.

• The mapping type decides the DMRS reference point : Type A counts from the slot boundary. Type B counts from the start of the allocation.
• Type A has to start early in the slot : S is limited to symbols 0 to 3. The DMRS at symbol 2 or 3 has to fall inside the allocation.
• Type B can start almost anywhere : S runs to symbol 12, and the allowed lengths are short.
• Latency is the reason type B exists : It removes the wait for the next slot boundary.
• The mapping type travels with k0 and the SLIV : All three come from the same row of the allocation table.

How does subcarrier spacing change these numbers ?

A K1 of 2 sounds like a fixed delay until the subcarrier spacing is named. It is not one. The slot is the unit, and the slot shrinks as the subcarrier spacing grows.

The consequence runs through the whole page. A K1 of 2 is 2 ms at 15 kHz and 0.25 ms at 120 kHz. The same configured number produces an eight times shorter delay, purely because of the numerology.

N1 and N2 move in the opposite direction, and that is the part worth watching. They are counted in symbols, and the symbol also shrinks with the numerology. A fixed processing time in microseconds therefore costs more symbols at a higher subcarrier spacing. That is why the N1 and N2 tables grow as mu increases rather than staying flat.

One more case appears when the scheduling DCI and the data use different numerologies, which happens with cross carrier scheduling. K0 is then applied after the slot number has been rescaled, using the ratio of the two subcarrier spacings. The K0 section diagram shows that rescaling as a formula. It collapses to a plain addition whenever the two numerologies are the same.

• A K value is not a duration : It counts slots. A slot is 1 ms at 15 kHz and 0.0625 ms at 240 kHz.
• The same K means very different delays : K1 equal to 2 is 2 ms at 15 kHz and 0.25 ms at 120 kHz.
• N1 and N2 grow with mu : Processing takes a similar time in microseconds, so it occupies more symbols when symbols are shorter.
• Cross carrier scheduling rescales the slot number : K0 is added after the ratio of the two subcarrier spacings has been applied.

What are the actual N1 and N2 values ?

This page explains what N1 and N2 are and where the capability is signalled, and I wanted the numbers in the same place. They are short tables, and having them here saves opening the specification for the common cases.

N1 is the PDSCH processing time, counted in symbols from the end of the PDSCH. TS 38.214 Table 5.3-1 holds the capability 1 values and Table 5.3-2 holds the capability 2 values.

The capability 1 column above is the case where dmrs-AdditionalPosition is pos0. When additional DMRS symbols are configured the UE needs longer, and Table 5.3-1 gives a second column for that. Capability 2 is the low latency capability, and it is only defined up to 60 kHz.

N2 is the PUSCH preparation time, counted in symbols from the end of the PDCCH that carried the grant. TS 38.214 Table 6.4-1 and Table 6.4-2 hold the two capabilities.

Two things are worth noticing in these tables. The first is that the values grow with mu, for the reason given in the section on subcarrier spacing. The second is that capability 2 is roughly half of capability 1, which is what makes it worth signalling at all.

Neither table is the whole calculation. The specification adds correction terms to N1 and N2 before comparing against the actual gap. Those terms depend on the mapping type, the DMRS configuration and the scheduling. The tables give the base value, which is what the scheduler starts from.

• N1 is measured from the end of the PDSCH : Capability 1 gives 8, 10, 17 and 20 symbols for mu 0 to 3.
• N2 is measured from the end of the PDCCH : Capability 1 gives 10, 12, 23 and 36 symbols for mu 0 to 3.
• Capability 2 is roughly half : It is the low latency capability, and it is defined only up to 60 kHz.
• Additional DMRS costs processing time : The capability 1 values above assume dmrs-AdditionalPosition is pos0.
• The tables are a base, not the final number : Correction terms are added before the gap is checked.

Reference

[1] 38.214 - 5G; NR; Physical layer procedures for data

[2] 38.331 - 5G; NR; Radio Resource Control (RRC); Protocol specification  

[3] 38.523

[4] R1-1721515 : 3GPP TSG-RAN WG1 Meeting #91 Summary of DL/UL scheduling and HARQ management  

[5] R1-1719401 : 3GPP TSG RAN WG1 Meeting 91 - Remaining issues on HARQ

[6] The impact of NR Scheduling Timings on End-to-End Delay for Uplink Traffic