5G NR parameters k0, k1, k2

This article offers a very brief and simplified description of the role of K0, K1 and K2 parameters in the time domain resource allocation and some key constraints imposed by 3GPP on them. For the sake of simplicity, it is assumed that PDCCH, PDSCH and PUSCH of the serving cell have the same numerology – otherwise the description would be a bit more complicated because different numerology of PDCCH and PDSCH/PUSCH would add extra rules. Also, for the sake of simplicity, graphical examples assume FDD, though nothing is different for TDD, i.e. TDD does not add any extra rules.

In general, any K-parameter determines the slot offset between the DCI the UE received on PDCCH channel and its scheduled resource – be it PDSCH reception (k0) or PUSCH transmission (k2) or HARQ feedback transmission over PUCCH (k1).

As usual, all the details and examples presented below can be found in NR RRC Reconfiguration message.

k0

k0 is a slot offset between DCI received by UE in PDCCH and its scheduled PDSCH. It can be found in the PDSCH- TimeDomainResourceAllocationList information element and can have integer value 0..32:

PDSCH-TimeDomainResourceAllocationList :

???????????????????????[0]: 
?????????????????????????k0: 0
?????????????????????????mappingType : typeA
?????????????????????????startSymbolAndLength: 40
???????????????????????[1]: 
?????????????????????????k0: 0
?????????????????????????mappingType : typeA
?????????????????????????startSymbolAndLength: 53
???????????????????????[2]: 
?????????????????????????k0: 0
?????????????????????????mappingType : typeA
?????????????????????????startSymbolAndLength: 54         

Slot offset k0 allows the resource allocation to be scheduled a specific number of slots in the future (k0 > 0), or for the resource allocation to be scheduled within the same current slot (k0 = 0). In real commercial network most likely you will never find any mentioning of k0 in your NR RRC Reconfiguration message. That’s absolutely fine because according to 3GPP TS 38.331, this field is optional and “When the field is absent the UE applies the value 0”. The UE knows that all PDSCH allocations always occur in the same slot where the PDCCH allocating them is. Your PDSCH-TimeDomainResourceAllocationList will rather look like this:

PDSCH-TimeDomainResourceAllocationList 
??????????????????????? [0]:
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 40
????????????????????? ??[1] :
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 96:        

There are a couple of interesting constraints imposed by 3GPP TS 38.214 w.r.t. k0 use:

• For any HARQ process ID(s) in a given scheduled cell, the UE is not expected to receive a PDSCH that overlaps in time with another PDSCH.
• For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start receiving a first PDSCH starting in symbol j by a PDCCH ending in symbol i, the UE is not expected to be scheduled to receive a PDSCH starting earlier than the end of the first PDSCH with a PDCCH that ends later than symbol i.

These constraints can be graphically presented as follows:

k1

k1 is in fact not named like this by 3GPP and this is rather a slang name. Its official 3GPP name is dl-DataToUL-ACK as seen in NR RRC Reconfiguration message or PDSCH-to-HARQ Feedback Timing Indicator as seen in DCI on PDCCH channel.

Interpretation of the PDSCH-to-HARQ Feedback Timing Indicator depends upon the DCI Format used to allocate the PDSCH resources. In the case of DCI Format 1_0, the timing indicator maps directly onto the set of values {1, 2, 3, 4, 5, 6, 7, 8}. In the case of DCI Format 1_1, the timing indicator represents a pointer towards a row within a look-up table configured by the RRC layer. This look-up table is configured as part of the PUCCH-Config parameter structure. The look-up table is called dl-DataToUL-ACK and can be configured with up to 8 rows which corresponds to the PDSCH-to-HARQ Feedback Timing Indicator field occupying up to 3 bits within DCI Format. The PDSCH-to-HARQ Feedback Timing Indicator determines the delay between the end of the slot used to transfer the PDSCH and the start of the slot used to return the HARQ acknowledgement.

dl-DataToUL-ACK provides a list of timing for given PDSCH to the DL ACK. It is a sequence of size 1..8 of integer values 0..15:

? ??????????????????dl-DataToUL-ACK
????????????????????? [0]: 3
????????????????????? [1]: 4
????????????????????? [2]: 5
????????????????????? [3]: 6
????????????????????? [4]: 7
????????????????????? [5]: 8
????????????????????? [6]: 11
????????????????????? [7]: 12        

One constraint for k1 is worth mentioning: In a given scheduled cell, the UE is not expected to receive a first PDSCH in slot i, with the corresponding HARQ-ACK assigned to be transmitted in slot j, and a second PDSCH starting later than the first PDSCH with its corresponding HARQ-ACK assigned to be transmitted in a slot before slot j. This constraint can be graphically presented as follows:

k2

k2 can have integer value 0..32 and it corresponds to the slot offset between the PDCCH carrying the DCI for the PUSCH allocation and the actual PUSCH to be allocated. When the field is absent the UE applies the value 1 when PUSCH SCS is 15/30 kHz; the value 2 when PUSCH SCS is 60 kHz, and the value 3 when PUSCH SCS is 120KHz. But it is never absent usually. But usually k2 fields are always present in real commercial networks.

All possible k2 values the serving cell may use for the UE can be found in the PUSCH-TimeDomainResourceAllocationList?structure that is used to configure a time domain relation between PDCCH and PUSCH. PUSCH-TimeDomainResourceAllocationList contains one or more of such PUSCH-TimeDomainResourceAllocations. The network indicates in the UL grant which of the configured time domain allocations the UE shall apply for that UL grant. The UE determines the bit width of the DCI field based on the number of entries in the PUSCH-TimeDomainResourceAllocationList. Value 0 in the DCI field refers to the first element in this list, value 1 in the DCI field refers to the second element in this list, and so on.

PUSCH-TimeDomainResourceAllocationList 
??????????????????????? [0]:
????????????????????????? k2: 1
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????????????????????? [1]:
????????????????????????? k2: 2
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????????????????????? [2]:
????????????????????????? k2: 3
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????????????????????? [3]:
????????????????????????? k2: 4
????????????????????????? mappingType: typeA
???????????????????? ?????startSymbolAndLength: 27
??????????????????????? [4]:
????????????????????????? k2: 5
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????????????????????? [5]:
????????????????????????? k2: 6
????? ????????????????????mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????????????????????? [6]:
????????????????????????? k2: 8
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27
??????? ????????????????[7]:
????????????????????????? k2: 9
????????????????????????? mappingType: typeA
????????????????????????? startSymbolAndLength: 27        

A couple of interesting constraint for k2 are worth mentioning:

• For any HARQ process ID(s) in a given scheduled cell, the UE is not expected to transmit a PUSCH that overlaps in time with another PUSCH.
• For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start a first PUSCH transmission starting in symbol j by a PDCCH ending in symbol i, the UE is not expected to be scheduled to transmit a PUSCH starting earlier than the end of the first PUSCH by a PDCCH that ends later than symbol i.

These constraints can be graphically presented as follows: