協定38.213（fd0版本）裡有這麼一段描述：
A UE does not expect to detect a DCI format scheduling a PDSCH reception or a SPS PDSCH release and indicating a resource for a PUCCH transmission with corresponding HARQ-ACK information in a slot if the UE previously detects a DCI format scheduling a PUSCH transmission in the slot and if the UE multiplexes HARQ-ACK information in the PUSCH transmission.
這段話大意是說，如果UE在slot n檢測到上行配置設定ul-grant，且對應的PUSCH資料在slot (n+k2)中發送，那麼UE将不會去檢測slot n到slot (n+k2)之間的下行資源配置設定dl-assignment，如下圖所示。
為什麼協定需要這麼規定？接下來我們來分析這背後的邏輯。
首先，在LTE裡，若UE需要在PUSCH中發送HARQ-ACK，UE會以打孔的形式（punctured）發送。而在NR裡，由于HARQ時序的不固定，以及HARQ-ACK的比特數更多，是以會存在兩種發送方式：
1、當HARQ-ACK比特數不超過2bits時，仍然采用類似LTE的打孔方式；
2、對超過2bits的HARQ-ACK，若仍然采用打孔的方式，将會增加PUSCH的碼率，降低解調性能，因而采用速率比對的方式（rate-matched）。
這在38.300（fa0版本）協定裡可以找到依據：
UCI multiplexing in PUSCH is supported when UCI and PUSCH transmissions coincide in time, either due to transmission of a UL-SCH transport block or due to triggering of A-CSI transmission without UL-SCH transport block:
- UCI carrying HARQ-ACK feedback with 1 or 2 bits is multiplexed by puncturing PUSCH;
- In all other cases UCI is multiplexed by rate matching PUSCH.
再來分析一下下面這種場景。
假定基站在slot n給UE下發了ul grant，對應的PUSCH在slot (n+4)。然後基站在slot (n+1)給UE下發了dl assignment，如果此時UE并沒有檢測到，即發生了漏檢行為。那麼此時對于UE來說，它并不知道基站已經給它發送了dl assignment，是以UE在slot (n+4)隻會發送資料，而不會複用HARQ-ACK，但基站仍然會按照PUSCH+ACK的方式解碼。
如果此時HARQ-ACK比特數隻有1或2比特，采用的是打孔的方式，那麼基站有可能能夠解析到PUSCH中的資料，但如果此時HARQ-ACK比特數超過了2比特，基站将會以速率比對的方式解析，此時PUSCH大機率會解碼失敗，如下圖所示。
是以，協定為了避免這種情況發生，規定在ul_grant和PUSCH之間，UE不再接收dl_assignment。
上述在ul grant之後收到dl assignment的場景，有2種可選方式解決：
方案1：限制後續dl assignment對應的HARQ ACK的比特數，并以打孔的方式在PUSCH中複用ACK。但這種方式會增加PUSCH的碼率，降低解調性能。
方案2：排程器在ul grant中預估後續需要發送的HARQ ACK比特數，UE基于該比特數，在PUSCH中進行速率比對，這樣即便dl assignment漏檢，也不影響基站對PUSCH的解碼。但這個方案的難點在于如何精準預估未來的HARQ比特數。
鑒于3GPP還未達成一緻意見，目前仍然不支援ul grant之後繼續處理dl assignment。