As
discussed in the post: Time Domain – Slots and Slot Formats, number of slots/symbols
available for transmission/reception varies depending upon the network
configuration. Therefore, it is important for the network to signal the UE
about the timing of data transmission/reception.
Signalling
of time-domain resources means, informing the UE about which slots/symbols the
data can be transmitted/received. Similar to LTE, NR resource allocation is done
either dynamically or in semi-persistent manner.
Dynamic
scheduling in the uplink is done using PDCCH DCI. For semi-persistent
scheduling, NR defines two mechanisms; one using PDCCH DCI (similar to LTE) and
the other one purely via RRC signalling (new in NR).
PDCCH
DCI is used for both dynamic and Semi-Persistent Scheduling (SPS) in the
downlink (similar to LTE).
Time-domain
PDSCH resource allocation is discussed in the post: PDSCH Resource Allocation in Time-Domain. In this post, uplink (PUSCH) resource allocation in
time-domain is discussed in detail.
2
PUSCH Resource Allocation in Time-Domain
2.1 Dynamic
Scheduling
Refer
to section 6.1.2.1 of 38.214 for more details.
In
NR, DCI formats 0_0 and 0_1 are used to dynamically allocate time-domain
resources for PUSCH. These DCI formats are thoroughly discussed in the post: DCI Formats in 5G NR.
In the case of dynamic scheduling, PDCCH
carrying DCI 0_0 and 0_1 are in general addressed to either C-RNTI or
MCS-C-RNTI. Temporary C-RNTI is also used during random access procedure.
DCI
formats 0_0 and 0_1 carries 4-bit field named ‘time domain resource
assignment’ which points to one of the rows of a look-up table. How the UE
determines which look-up table to be used is discussed in section 2.1.2.
There
can be up to 16 rows in the look-up table and hence only 4-bits are used
for the field ‘time domain resource assignment’ and value ‘m’ for
this field points to row number ‘m+1’ within the look-up table.
Each row in the look-up table provides the following
parameters;
-
slots
offset K2. This parameter is used to derive the slot in which
PUSCH transmission occurs.
-
SLIV (jointly coded Start and Length Indicator Values), or
individual values for the start symbol ‘S’ and the allocation length ‘L’.
-
‘PUSCH
mapping type’ to be applied on the PUSCH transmission.
The
contents of the look-up table are summarised below;
Parameter
|
Explanation
|
K2
|
Used to derive the slot offset from the slot where DCI is received |
S
|
’S’ is the ‘start symbol’ -> First symbol in the slot in which PUSCH will be transmitted |
L
|
Allocation length in number of OFDM symbols. |
SLIV
|
Start and Length values are jointly encoded to produce Start and Length Indicator Value (SLIV) |
PUSCH mapping type
|
PUSCH mapping type (Type A or Type B) to be applied in the PUSCH transmission. This helps determining the first DM-RS symbol position. |
The following figure illustrates an example with time domain resource assignment field in DCI 0_0/0_1 indicating (based on look-up table) K2 = 1, S = 4 and L = 6.
In
the above illustration, it is assumed that SCS for PUSCH and PDCCH are
same.
It
is possible that network configures different SCS for PDCCH and PUSCH.
Determining slot offset based on just K2 is not sufficient if
SCS for PDCCH and PUSCH are different. In such cases, the slot where the
UE shall transmit the PUSCH is calculated according to the below equation;
\[The\:slot\:number\:allocated\:for\:PUSCH\:=\:\Big \lfloor n.\dfrac{2^{\mu_{PUSCH}}}{2^{\mu_{PDCCH}}} \Big\rfloor + K_2\]
\[The\:slot\:number\:allocated\:for\:PUSCH\:=\:\Big \lfloor n.\dfrac{2^{\mu_{PUSCH}}}{2^{\mu_{PDCCH}}} \Big\rfloor + K_2\]
where
n is the slot with the scheduling DCI, K2 is based on
the numerology of PUSCH, and µPUSCH and µPDCCH
are the subcarrier spacing configurations for PUSCH and PDCCH, respectively.
Considering
same example from the above illustration, K2 = 1, S =
4, L = 6, µPUSCH = 2, and µPDCCH = 0
=> if the DCI is received in slot number 1 (using PDCCH SCS), the
PUSCH will be transmitted in the slot number 5 (= 4+1 based on the above
equation) using PUSCH SCS. Note that in this example, there are 4 times
more number of slots with PUSCH SCS as compared to PDCCH SCS.
2.1.1 Valid
‘S’ and ‘L’ combinations:
Not
all start and length values are valid due to the fact that a single time-domain
resource allocation must be contained within a slot i.e., the allocation should
not cross the slot boundary.
Moreover,
the number of symbols in a slot varies with cyclic prefix which will also limit
number of allowed start and length combinations => for normal CP, a slot
contains 14 OFDM symbols and with extended CP, 12 OFDM symbols form a slot.
The
UE shall consider the S and L combinations defined in table below
as a valid PUSCH allocations. Note from column ‘S+L’ that the sum of
start symbol number and allocation length should not exceed 14 for normal CP
and 12 for extended CP.
PUSCH Mapping Type
|
Normal cyclic prefix
|
Extended cyclic prefix
|
||||
S
|
L
|
S+L
|
S
|
L
|
S+L
|
|
Type A
|
0
|
{4,...,14}
|
{4,...,14}
|
0
|
{4,…,12}
|
{4,…,12}
|
Type B
|
{0,...,13}
|
{1,…,14}
|
{1,…,14}
|
{0,…,11}
|
{1,…,12}
|
{1,…,12}
|
There
are two types of PUSCH resource allocation tables (look-up tables);
1.
“default PUSCH time domain allocation table A”:
A predefined table in 38.214, Table 6.1.2.1.1-2 for normal CP and Table
6.1.2.1.1-3 for extended CP.
2.
RRC configured table pusch-TimeDomainAllocationList
sent in either pusch-ConfigCommon (sent via SIB1 or dedicated RRC
signalling) or pusch-Config (sent via dedicated RRC signalling)
The
UE will choose appropriate table based on several factors like which of the
above tables is configured in the UE, RNTI, search space type etc… Table 6.1.2.1.1-1
in 38.214 specifies the table selection criteria and is presented below for a
quick reference.
RNTI
|
PDCCH search space
|
pusch-ConfigCommon includes TimeDomain AllocationList
|
pusch-Config includes TimeDomain AllocationList
|
PUSCH time domain resource allocation to apply
|
PUSCH scheduled by MAC RAR (uplink grant received within RAR)
|
No
|
N/A
|
Default A
|
|
Yes
|
N/A
|
pusch-TimeDomainAllocationList from pusch-ConfigCommon
|
||
C-RNTI,
MCS-C-RNTI,
TC-RNTI,
CS-RNTI
|
Any common search space associated with CORESET0 |
No
|
N/A
|
Default A
|
Yes
|
N/A
|
pusch-TimeDomainAllocationList from pusch-ConfigCommon
|
||
C-RNTI,
MCS-C-RNTI,
TC-RNTI,
CS-RNTI,
SP-CSI-RNTI
|
Any common search space NOT associated with CORESET0, (or) UE-specific search space |
No
|
No
|
Default A
|
Yes
|
No
|
pusch-TimeDomainAllocationList from pusch-ConfigCommon
|
||
No/Yes
|
Yes
|
pusch-TimeDomainAllocationList from pusch-Config
|
||
Notes
from the above table;
-
default
PUSCH time domain allocation table A is chosen in cases where TimeDomainAllocationList
is not configured by either pusch-ConfigCommon or pusch-Config
(for applicable cases).
-
If
available, TimeDomainAllocationList provided by pusch-ConfigCommon is
always used except for a case where the same list is also provided by pusch-Config
and the concerned search space is either UE-specific or common search space not
associated with CORESET0.
-
If
TimeDomainAllocationList is provided by pusch-Config and the
concerned search space is either UE-specific or common search space not
associated with CORESET0, then TimeDomainAllocationList is used.
There is an additional slot delay value defined for
the first transmission of PUSCH scheduled by the RAR grant. This slot delay
increases with SCS. When the UE transmits a PUSCH scheduled by RAR, the ∆
value specific to the PUSCH subcarrier spacing is applied in addition to the K2
value i.e., total slot offset applied is equal to K2 + ∆. The
additional slot delay (∆) values are as shown below;
SCS
|
Additional slot delay value ( ∆ )
|
15 kHz
|
2
|
30 kHz
|
3
|
60 kHz
|
4
|
120 kHz
|
6
|
2.1.2.1 Default PUSCH time-domain allocation table A
“Default
PUSCH time domain resource allocation table A” is shown below for both
normal CP and extended CP. As the number of symbols per slot varies depending
upon CP, only length (in symbols) is different in the case of extended CP.
Row index
|
PUSCH mapping type
|
K2
|
S
|
L
|
|
Normal CP
|
Extended CP
|
||||
1
|
Type A
|
j
|
0
|
14
|
8
|
2
|
Type A
|
j
|
0
|
12
|
12
|
3
|
Type A
|
j
|
0
|
10
|
10
|
4
|
Type B
|
j
|
2
|
10
|
10
|
5
|
Type B
|
j
|
4
|
10
|
4
|
6
|
Type B
|
j
|
4
|
8
|
8
|
7
|
Type B
|
j
|
4
|
6
|
6
|
8
|
Type A
|
j + 1
|
0
|
14
|
8
|
9
|
Type A
|
j + 1
|
0
|
12
|
12
|
10
|
Type A
|
j + 1
|
0
|
10
|
10
|
11
|
Type A
|
j + 2
|
0
|
14
|
6
|
12
|
Type A
|
j + 2
|
0
|
12
|
12
|
13
|
Type A
|
j + 2
|
0
|
10
|
10
|
14
|
Type B
|
j
|
8
|
6
|
4
|
15
|
Type A
|
j + 3
|
0
|
14
|
8
|
16
|
Type A
|
j + 3
|
0
|
10
|
10
|
| j = {1, 1, 2, 3} for SCS = {15 kHz, 30 kHz, 60 kHz, 120 kHz} respectively | |||||
Note
from the above table, slot offset ‘K2’ values are always
non-zero, meaning that PUSCH transmission never starts in the same slot where
allocation is received.
2.1.2.2 TimeDomainAllocationList
TimeDomainAllocationList
is configured by either pusch-ConfigCommon or pusch-Config.
The
IE PUSCH-TimeDomainResourceAllocation is used to configure a time-domain
relation between PDCCH and PUSCH. PUSCH-TimeDomainResourceAllocationList contains
one or more (up to 16) of such PUSCH-TimeDomainResourceAllocations.
The
UE determines the bit width of the DCI field based on the number of entries in
the PUSCH-TimeDomainResourceAllocationList.
The
network indicates in the UL grant (DCI) which of the configured time domain
allocations the UE shall apply for that UL grant. 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
IE structure is shown below. It contains K2,
PUSCH mapping type, and startSymbolAndLength (SLIV).
| PUSCH-TimeDomainResourceAllocationList | |
| PUSCH-TimeDomainResourceAllocationList | List from 1 up to 16 PUSCH-TimeDomainResourceAllocation |
| PUSCH-TimeDomainResourceAllocation | |
| k2 | INTEGER (0..32) |
| mappingType | ENUMERATED {type A, type B} |
| startSymbolAndLength | INTEGER (0..127) |
-
The
value of K2 ranges from 0 to 32 => unlike default table
A, this method of allocation allows for PUSCH transmission within the same
slot (K2 = 0) where the allocation is received. When
allocation and PUSCH transmission are contained in the same slot, it is
referred to as ‘self-contained’ slot.
-
When
K2 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.
-
startSymbolAndLength
provides an
index giving valid combinations of start symbol and length (jointly encoded) as
start and length indicator (SLIV). The network configures the field so
that the allocation does not cross the slot boundary.
As
can be noted, in this option, the network doesn’t give individual values of
starting symbol ‘S’ and length value ‘L’, instead, a jointly
encoded value (SLIV) is provided.
The ‘S’ and ‘L’ values
allocated for the PUSCH are determined from the SLIV as shown below:
if
(L − 1) ≤ 7:
SLIV = 14.(L − 1) + S
else:
SLIV = 14⋅(14 − L + 1) + (14 − 1 − S)
where 0 <
L ≤ 14 − S
2.1.3 PUSCH
mapping type:
Refer
to section 6.4.1.1.3 from 38.211 for more details.
PUSCH
mapping type defines the DM-RS configuration of PUSCH transmissions. Depending
upon the location of first DM-RS symbol, there are two mapping types defined; type
A and type B.
As
discussed already, time domain resource assignment field within the DCI
points to a row number within the look-up table and each row defines PUSCH
mapping type (either type A or type B) to be followed.
PUSCH
mapping type A:
In type A, DM-RS is mapped relative to the start
of the slot irrespective of which symbol in the slot the PUSCH
transmission starts.
When frequency hopping is disabled, the DM-RS position
is defined to start relative to the start of the slot boundary and relative to
start of each hop in case if frequency hopping is enabled.
The position of the first DM-RS symbol for type A is
configured by RRC via either MIB or via ServingCellConfigCommon (SIB1 or dedicated
signalling). The field dmrs-TypeA-Position is used for this
purpose. This field takes two values pos2 or pos3.
First symbol of DM-RS is located at either symbol 2 (pos2) or at symbol
3 (pos3) within the slot.
| dmrs-TypeA-Position | ENUMERATED { pos2, pos3 } |
PUSCH mapping type B:
In type B, DM-RS is mapped relative to the start
of the PUSCH allocation rather than start of the slot boundary.
To be precise, the DM-RS location is the first OFDM
symbol where PUSCH transmission starts if frequency hopping is disabled and
relative to the start of each hop in case frequency hopping is enabled.
In this case, as the DM-RS start symbol is fixed, the
network need not explicitly provide configuration for type B.
Valid
S and L combinations:
‘S’
and ‘L’ values are defined separately for each PUSCH mapping type
because, not all combinations are valid for a given mapping type.
PUSCH Mapping Type
|
Normal cyclic prefix
|
Extended cyclic prefix
|
||||
S
|
L
|
S+L
|
S
|
L
|
S+L
|
|
Type A
|
0
|
{4,...,14}
|
{4,...,14}
|
0
|
{4,…,12}
|
{4,…,12}
|
Type B
|
{0,...,13}
|
{1,…,14}
|
{1,…,14}
|
{0,…,11}
|
{1,…,12}
|
{1,…,12}
|
From the above table, it can be seen that, for PUSCH
mapping type A, start symbol ‘S’ is always symbol ‘0’ because it
makes sense to start before symbol 2 which can be the first DM-RS location for type
A (pos2).
2.2 Semi-Persistent
Scheduling
For
uplink SPS, PDCCH carrying DCI 0_0 and 0_1 is addressed to Configured
Scheduling-RNTI (CS-RNTI). In LTE, SPS-C-RNTI is used
for this purpose. The grant received using CS-RNTI is referred to as configured
grant.
Similar
to uplink SPS in LTE, configured grant is given by the network to
the UE who stores the received grant and uses it according to the
pre-configured timing given by the network.
Configured
grant will be discussed thoroughly in a separate post.
Unlink
LTE, NR has two types of configured grants defined. Type 1 and Type 2.
Note
that the discussions in section 2.1 above are valid for configured grants as
well except for the way the network informs the UE about the time-domain
resource allocation.
2.2.1 Time-domain
resource allocation in configured grant type 1
In
configured
grant Type 1, the resource allocation is done using RRC.
Only for re-transmissions, PDCCH DCI 0_0 or 0_1 addressed to CS-RNTI is used.
The
following table provides part of the RRC configuration for configured grant
Type 1. The intention is to highlight how the time-domain resource
allocation is done.
| rrc-ConfiguredUplinkGrant | |
| timeDomainOffset | INTEGER (0..5119) |
| timeDomainAllocation | INTEGER (0..15) |
| frequencyDomainAllocation | BIT STRING ( SIZE (15) ) |
| . . . | |
timeDomainOffset
provides an offset relative to SFN = 0. The UE
activates the configured grant after the offset configured by this
parameter.
Similar
to dynamic scheduling, timeDomainAllocation field from above table indicates
a combination of start symbol ‘S’ and length ‘L’ and PUSCH
mapping type.
A
value ‘m’ for the field timeDomainAllocation points to row number
‘m+1’ within the look-up table. The rules to determine which look-up
table to be used is exactly same as those discussed in sections 2.1.2 above.
In
this type of resource allocation, once the network configures time-domain
resource using RRC, the only way to change the allocation is by re-configuring
the parameters by sending another RRCReconfiguration message to the UE.
2.2.2 Time-domain
resource allocation in configured grant type 2
Configured
grant type 2 in NR is similar to that of uplink SPS in LTE.
In
configured grant Type 2, the time-domain resource allocation is done
using PDCCH DCI (format 0_0 or 0_1) addressed to CS-RNTI. Even for
re-transmissions, PDCCH DCI 0_0 or 0_1 addressed to CS-RNTI is used.
Once
configured using DCI 0_0 or 0_1, the UE periodically uses same time-domain
resources until the configured grant is re-activated (kind of reconfiguration
at MAC level).
As
the time-domain resource allocation is done using DCI 0_0 or 0_1 (similar to
dynamic allocation), all the discussions in section 2.1 are valid for configured
grant type 2 as well.
3
Slot Aggregation:
Slot
aggregation improves the uplink (cell edge) coverage. In a cell edge scenario,
the probability of incorrectly decoding PUSCH is more, so instead of waiting
confirmation from the gNB, it would be beneficial to (re-)transmit PUSCH in
consecutive slots.
With
slot aggregation data transmission can span over multiple slots i.e the UE
would transmit same TB across a pre-configured number of consecutive slots.
Same
HARQ process is used for each transmission that is part of the same bundle.
Within a bundle, HARQ retransmissions are triggered without waiting for feedback
from previous transmission.
In
the first step, the network configures slot aggregation via RRC signalling;
- pusch-AggregationFactor
within PUSCH-Config IE is used for the case of dynamic scheduling. This
field can take values of 2, 4 or 8 repetitions as shown below;
| pusch-AggregationFactor | ENUMERATED { n2, n4, n8 } |
-
repK within ConfiguredGrantConfig
IE for the case of configured grant. This field is mandatorily
present and takes values of 1, 2, 4, and 8. Slot aggregation is activated when repK
> 1.
| repK | ENUMERATED { n1, n2, n4, n8 } |
In
the second step, network sends DCI format 0_1 on PDCCH with CRC scrambled with C-RNTI or
MCS-C-RNTI for dynamic grant and CS-RNTI with NDI=1 for configured grant.
The
UE follows the below procedure considering pusch-AggregationFactor is
applicable for dynamic scheduling and repK is applicable for configured
uplink grant;
-
When
the MAC entity is configured with pusch-AggregationFactor > 1 or repK
> 1, the parameter pusch-AggregationFactor/repK provides the number
of transmissions of the same TB within a bundle.
-
After
the initial transmission, pusch-AggregationFactor – 1 or repK – 1
HARQ retransmissions follow within a bundle.
-
Same
HARQ process is used for each transmission that is part of the same bundle.
-
The
UE shall repeat the TB across the pusch-AggregationFactor/repK consecutive
slots applying the same symbol allocation in each slot.
-
For
dynamic scheduling, the redundancy version to be applied on the nth
transmission occasion of the TB, where n = 0, 1, ... (pusch-AggregationFactor
- 1), is determined according to table below.
rvid indicated by the DCI scheduling the PUSCH
|
rvid to be applied to nth transmission occasion
|
|||
n mod 4 = 0
|
n mod 4 = 1
|
n mod 4 = 2
|
n mod 4 = 3
|
|
0
|
0
|
2
|
3
|
1
|
2
|
2
|
3
|
1
|
0
|
3
|
3
|
1
|
0
|
2
|
1
|
1
|
0
|
2
|
3
|
-
For
configured grant, the parameter repK-RV (if configured within configuredGrantConfig
IE) is used to derive the redundancy version pattern to be applied to the
repetitions. If this parameter repK-RV is not configured, the
redundancy version for uplink transmissions shall be set to 0. Refer to section
6.1.2.3 of 38.214 for more details.
| repK-RV | ENUMERATED { s1-0231, s2-0303, s3-0000 } |
Note
that when slot aggregation is active, the PUSCH is limited to a single
transmission layer.
The
following example illustrates PUSCH slot aggregation;
Reference: 3GPP TS 38.211, 38.212, 38.213, 38.214, and
38.331
