5G/NR - Dynamic Scheduling Home : www.sharetechnote.com
NR scheduling offers super wide flexibility that get so many factors involved. However, in practice 'wide flexibility' often mean 'too high degree of complexity', 'difficulties of understanding the details' and 'confusion'. Mainly due to this complexity, I have written several individual notes that are directly or indirectly related to NR scheduling. Followings are the list of my notes related to NR scheduling. Don't try to understand all of these at once. You may get overwhelmed and may end up with early give-up. Start with reading through these notes without being pressured to understand all the details with the first read. Just try to pick up some terminologies and factors related to scheduling.
In this note, I want to approach NR scheduling with more of practical perspectives with the minimum set of factors. At least as of now (Oct 2021), the industry seems to keep the scheduling as simple as possible and not to enable tricky features (e.g, configured scheduling, SFI and introduction of cancellation, interruption etc) which may lead to too much complication and unstability of the scheduling.
If you are interested in NR scheduling, it would be good idea to have a firm understandings on this note and try to deepen / widen the knowledge and experience from there.
Now let's look into a typical downlink scheduling (i.e, PDSCH scheduling). This process can be illustrated as follows, the process can be summarized as follows.
i) NW (Network) send DCI for PDSCH (PDSCH Grant)
ii) After K0 slots after the DCI, PDSCH is transmitted (K0 can be any value from 0 through 32, but as of Sep 2021, only K0 = 0 seems to be supported).
iii) After k1 slots after the PDSCH is transmitted, UE transmit Ack/Nack via UCI. The UCI can be carried by PUCCH or PUSCH depending on situations. The slot carrying the UCI can be utilized in various different form which can be examplified as Case 1,2,3,4 as shown below).
NOTE : The above illustration shows several typical forms of the UCI slot (the slot carrying the UCI). In this illustration, I just presented only 4 different cases but there can be more cases.
Uplink scheduling is relatively simple comparing the downlink scheduling explained in previous section. Overall procedure is as follows.
i) Network send UL Grant(DCI 0_0 or DCI 0_1).
ii) After K2 slot after the DCI slot, UE transmit PUSCH.
NOTE : As you see here, there is no ACK/NACK report for PUSCH. Then what would happen Network failed to recieve / decode PUSCH ? In that case, Network request UE to retransmit PUSCH. Then next question would be How Network can request retransmit ?. There is no special mechanism (e.g, special DCI for retransmission). Network just send the same UL Grant(DCI) with NDI value NOT toggled. This is interpreted as 'retransmittion request' on UE side.
The scheduling procedure describe in previous section is for the scheduling in single cycle (i.e, single HARQ process). If only the single cycle (single HARQ) is used, there would be a lot of slots being idle(i.e, not scheduled) because almost always there are some slots not scheduling between PDSCH and UCI, and between DCI and PUSCH. So in most of real situation, multiples of those individual process (individual HARQ processes) are running in interleaving fashion and it can minimize the number of not-used slots.
In this section, I will show you some of the examples of the scheduling you may see in live network situation or test setups for high throughput. These are only a few examples, there can be almost infinite number of different way of scheduling method.
Example 01 : DDDDSDDDDS
In this example, the scheduling is done in periodic fashion. Each period spans 5 slots in which the first 4 slot is scheduled for PDSCH and the fifth slot is reserved for UCI. Ack/Nack for all the PDSCH within the 5 slot span is conveyed by the single UCI in the fifth slot. Looking further into UCI slot, it can be scheduled as in a case out of 4 cases shown here.
NOTE : When scheduling happens with a certain repeating pattern like this, Network May (or May Not) configure tdd-UL-DL-ConfigCommon in Rrc.
Example 02 : DDDDSDDDDS
In terms of overall slot configuration, the pattern in this example is same as the pattern in previous example. The difference from the previous example is that UCI for some PDSCH within a period is mapped to the UCI slot in next period. Like a previous example, the UCI slot can be scheduled as in a case out of 4 cases shown here.
Example 03 : DDDUSDDDUS
This example also shows a scheduling with a specific pattern(5 slot pattern) where the first 3 slots are scheduled for PDSCH and the 4th slot is scheduled for PUSCH and the last (5th slot) is reserved for UCI. Like a previous example, the UCI slot can be scheduled as in a case out of 4 cases shown here.
NOTE : If the UCI slot structure is like Case 1,3,4 of the 4 cases shown here, this pattern May (or May not) be configured as tdd-UL-DL-ConfigCommon in Rrc.
Example 04 : DDDDSDDSUU
In this example, I just try to break the pattern to show you that the scheduling can be done in any arbitray way. I put the first 5 slots in the same pattern as in example 01 and in the second 5 slots I put 2 PDSCH at the beginning and 2 PUSCH slots at the end and put UCI slot in the middle. In terms of UCI transmission as well, I mapped one UCI in the same way as above and mapped another UCI to PUSCH.
NOTE : Even in this case, you may apply some pattern if you try hard. If you define the length of the pattern to be 5 slots, there is no pattern. But if we assume that this 10 slot scheduling repeats then you can take the 10 slots as a pattern.
NOTE : If you want, you can even apply tdd-ul-dl-ConfigCommon to this kind of pattern if this 10 slot scheduling repeats. You cannot apply TDD UL/DL Configuration Common with Pattern 1 only since there are multiple DL/UL switching points in the pattern. But if you break this 10 slots into two 5 slots, you can apply tdd-ul-dl-ConfigCommon using the two patterns (i.e, Pattern 1 and Pattern 2)
Example 05 : XDDXSDDSXU
The previous examples would show you the most of the cases for scheduling regular slots (By regular slot, I mean those slots that can be fully allocated for user data(e.g, PDSCH, PUSCH) and control information (e.g, DCI, UCI)). But there are some slots that cannot be used fully for user data and control information. Let me call this as a 'special purpose slot' (this is not 3GPP term). By special purpose slot, I mean those slots transmitting special reference signals (e.g, SSB, CSI-RS, TRS) or reserved for special usage(e.g, Rach Occasion(RO)). Following is an example of these special purposed slots scattered here and there between regular slots.
For the regular slots you may schedule the same way as you saw in previous examples, but what about those special purpose slots (i.e, SSB slot, CSI-RS slot, RO slot) ?
Just for perspective of scheduling, the simplest way is 'Do NOT schedule/allocate any PDSCH, PUSCH' in these slots. It can avoid many problems that can happen related to channel encoding/decoding. In reality, at early implementation / deployment of 5G, you might have seen those cases where network does not allocate PDSCH or PUSCH in those special purpose slots.
However utilizing those slots only for transmitting / receiving the special signals is waste of resources because the number of resources (i.e, Resource Elements) required for those special signal is very small portion comparing to the whole resources available for those slots. As 5G/NR implementation and deployment gets more mature, you would see more and more of those cases where even these special purpose slots are utilized for transmitting or receiving user data. 3GPP allows or provide mechanisms to transmit/recieve user data in these special purpose slots from the beginning (i.e, Release 15), but in early implementation those special purpose slots tend NOT to be used for user data.
NOTE : Refer to 3GPP document mentioned in the following sections for the detail. You would notice that there are many details you need to take into accounts when you want to use those sepcial purpose slots for user data. If situation allows, just not to allocate any use data for those slot would be the simplest and remove a lot of headache -:).
What I have described above is based on typical scheduling that are commonly practiced in the live network or testing environment. Most of the cases shown above would look obvious to you, but there are many cases where the scheduling may not look obvious especially when the scheduling(Scheduling by DCI 1_x and DCI 0_x) is done when tdd-UL-DL Configcommon / tdd-UL-DL ConfigDedicated are configured or SlotFormat Combination is configured by Rrc and SFI (DCI 2_x).
38.214-5.1.4 describes the details on exactly when/where you can allocate PDSCH. You should understand in-depth about this part if you want to schedule PDSCH in those special purpose slot as in Example 05.
38.213 - 11.1 describes on various cases that requires special attention for scheduling. In most cases, you may not need to worry about those special cases (corner cases) since most live network or test equipment perform the scheduling in such a way that does not lead to such a corner cases, but it would be good idea to look into those special cases when you have scheduling issues and failed to figure out root causes after you examined all the typical cases described above.